As organizations rapidly deploy AI-enabled systems, many failures are emerging not from the model itself but from how the surrounding system turns model outputs into consequential actions. At ISC2 Security Congress 2026, Diane Jones, CISSP, CCSP, explored that distinction.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Imagine an AI assistant preparing to send a document to someone outside the organization. The message reads well. The attachment looks relevant. The assistant has done exactly what it was asked to do. But is the recipient authorized to receive that information? And, just as critical, who will stop the message if the answer is no?
This scenario featuring the what-ifs of agentic AI highlights when a conversation about AI behavior becomes a conversation about AI control. At ISC2 Security Congress 2026, Diane Jones, CISSP, CCSP, explored that distinction in her session Governing What AI Systems Are Allowed to Do: The AI Admissibility Framework. The issue at hand goes well beyond whether AI produces good outputs, focusing instead on whether the organization can put the brakes on autonomous action that shouldn’t happen at all.
Enter AI governance. Jones noted that, “Once model output can drive action, the governance question becomes: ‘Should this proposed action be allowed to proceed?’” The problem is that “AI-enabled systems can act, but governance is often disconnected from execution.”
Responding to this reality, Jones presented an AI Admissibility Framework to give organizations a way to address this fundamental AI control problem, which encompasses several factors that demand a governance structure that transcends the agentic AI actions:
- Policies and frameworks do not operate the system
- Testing and red-teaming observe behavior; they cannot cover every possible path
- Guardrails and prompts can shape behavior, but they do not create an enforceable boundary around what the system may do
In short, as Jones said, “The question is not only whether the model behaves well. It is whether the surrounding system can decide and enforce what is allowed”.
AI Governance at the Moment of Action
Organizations often adopt several ways to influence AI behavior: policies, prompts, guardrails, testing and red-teaming. Each has a role, of course. None, on its own, however, guarantees that every action an AI-enabled system attempts will stay within the organization’s rules and traditional controls.
Indeed, a policy can prohibit sharing restricted information, but it cannot intercept a message. A successful test can show how a system behaved yesterday, but it cannot establish permission for every situation it encounters tomorrow, especially given changing context. The gap between control and AI action, therefore, becomes harder to ignore when AI is given the agency to change records, use tools or trigger workflows.
It is this fundamental question of admissibility that brings governance to that moment of action. Before something consequential happens, the system checks whether the required conditions are satisfied. If not, the AI denies the action, waits for conditions to change or sends the decision for review. Permission is established, not assumed.
The AACE AI Admissibility Framework
Jones presented the AI Admissibility AACE framework (authority, actions, context and evidence) as a way for organizations to work through this foundational decision-making of AI agents.
Now, consider again the hypothetical assistant about to send a document. What does action look like now within the AACE framework?
- Authority asks whether the assistant has permission to send it on someone’s behalf. Access to an email tool should not automatically confer every privilege held by the person using it.
- Actions asks whether sending the document falls within the assistant’s approved purpose. Being able to perform an operation is different from being authorized to perform it.
- Context asks whether the circumstances support proceeding now. Is the recipient approved? Is the information current? A document retrieved to help prepare the message is input, not an authority that can grant permission.
- Evidence establishes the basis for the decision and preserves what happened: what was proposed, which conditions were checked, whether permission was granted and what actually executed.
These are not four boxes to tick once at deployment. Instead, they are dynamic elements. If the circumstances change, the answer may change with them.
The Permission Check Must Hold
Answering those questions set forth by the framework is useful, however, only if the system can enforce the result. The boundary belongs where the consequence occurs: before the message leaves, the record changes or the workflow advances.
There is no single product that supplies this boundary everywhere. An authorization service, API gateway or workflow interlock may do the job, depending on the action. The right mechanism is the one that can actually prevent the consequence.
Two requirements make that control meaningful. The assistant cannot be the final judge of its own request, and it cannot have another route around the decision. Requiring approval through one channel accomplishes little if the same document can leave through another, unchecked path.
Accordingly, the enforcement mechanism also needs protection from the system it constrains, reliable information and enough detail to understand what an action means. It must account for cumulative effects, too. Consider, for instance, that several apparently acceptable steps can add up to an outcome the organization would never approve as a whole.
A New Challenge, Familiar Security Foundations
The session connected this current concept of AI admissibility to several classic security models:
- Reference Monitor for checking every relevant access
- Bell–LaPadula for constraining information flow
- Biba for protecting integrity
- The Trusted Computing Base for reliable enforcement
- Clark–Wilson for controlled transactions
These classic security models make admissibility enforceable. As Jones noted, “AACE defines the conditions for admissibility; security architecture makes the decision enforceable”.
Start Where AI Can Change Something
A practical first step is to trace one AI-enabled workflow from recommendation to execution. Identify the point where something changes, then ask what must be true before the change is allowed and, importantly, what happens when it is not.
That exercise can expose an uncomfortable distinction: the organization may have a clear policy without a working means of enforcing it.
Checks may introduce friction. Some actions will wait; others will require review. The question is whether that friction protects a necessary boundary, not simply whether automation can remove it.
Now, think about that AI assistant with the document ready to send. A polished message is not the final measure of success. The real test is whether the system can recognize that permission is missing and keep the message from leaving. That is governance doing its job with the help of Jones’s AI Admissibility Framework.
Learn more about ISC2 Security Congress 2026 Sessions
Virtual and in-person attendees to Congress can see an on-demand replay of the session this article is based on as part of their existing access. On-demand access packages for Congress sessions will be available at a later date.
