AI agent authorization and control

AI agents and agentic systems need more than identity and authorization. They need decision boundaries, context control, and operational guardrails around what they can access, decide, and trigger based on context, situation, and state. That all sits outside the scope of traditional authorization and falls under the umbrella of decision governance for AI agents.

Microsoft is right to move the conversation beyond identity. Its recent security guidance makes an important point: identity alone is not enough for agents. Before an agent invokes a tool or a protected API, the runtime should evaluate that action and return a deterministic result such as ALLOW, DENY, REQUIRE_APPROVAL, or MASK. Microsoft describes this as runtime authorization beyond identity.

That is the right direction. For AI Agents, though, there is a missing layer. That layer is admissibility.

Two-Layer Authorization

The need for AI agents identity and authorization can be addressed via two check gates.

Gate 1: Authorization and Tool Access
The first gate is about general authority. It answers questions like:

Who is the actor
What tenant, modules, and resources it can access
Which tools it can use in general

This is the platform and security gate. It fits Microsoft’s direction around agent identity and runtime authorization before tool execution. But Gate 1 is still not enough. An agent may be authorized to operate in claims, refunds, or pricing, and it may have access to certain tools and resources. That still does not answer the business question: What actions is this actor allowed to take for this input, in this situation, within this context?

Gate 2: Admissibility
That is the second gate. Admissibility in Decision Governance is the explicit, versioned, testable, and controlled at runtime with a decision model that determines what actions an actor is allowed to take for a specific case in its current situation and context.

This is not static configuration. Authorization can be partly static, but admissibility is contextual and situational. It must be resolved at runtime. So the two gates are different:

Gate 1 says what is generally accessible and authorized.
Gate 2 says what actions this actor is allowed to take now for this case, in this situation, within this context. And enforces at runtime execution boundary.

If query time and commit time are separate, admissibility must be re-evaluated at commit time, because context, state, evidence, approvals, or business conditions may have changed.

Why Admissibility Belongs to Decision Governance

Admissibility belongs to Decision Governance because admissibility is a business decision. It is not merely a security rule, a technical permission, a workflow condition, or a platform guardrail. It answers the business question: What actions may be taken now for this case, in this situation, within this context?

That is a decision. A permission check asks if this actor can access this tool, whereas admissibility asks if this actor should be allowed to take this business action now. Those are not the same category. The second one is a business judgment about context, evidence, state, policy, consequence, and the next step. That is why admissibility is not outside Decision Governance; it is one of its runtime decision models.

Admissibility Without Decision Governance

Strictly speaking, there is no such thing as admissibility outside Decision Governance. What exists outside Decision Governance is not admissibility in the proper sense; it is only fragmented control logic spread across workflow conditions, approval rules, policy checks, state transitions, tool permissions, and hard-coded exceptions.

Those mechanisms may restrict behavior, but they do not form an explicit business decision model. They do not make admissibility visible, versioned, testable, controlled, or governable as a first-class decision. Without Decision Governance, there is no admissibility, only fragmented control logic buried inside automation or admin panels.

With Decision Governance: Admissibility is an explicit, versioned, testable, and controlled runtime decision model.
Without Decision Governance: There is no admissibility, only fragmented control logic buried inside automation or admin panels.

This is Where Decision Governance Matters

Without Decision Governance, the runtime answer usually ends up buried across workflow conditions, approvals, policies, tool permissions, exception handling, and state transitions. The logic exists, but it is hidden.

Decision Governance changes that by making admissibility a first-class decision model. That means the answer to what actions can be taken now, under what context, under what authority, at what stage, and with what execution boundary is no longer buried inside automation; it becomes a governed decision asset.

A Simple Example
Take a refund case.

Gate 1 says:
The refund agent may read customer history, read refund policy, use review tools, and use payout tools. That is general authorization.

Gate 2 says:
For this specific refund request, proof of purchase is missing, the amount exceeds the threshold, and the customer claim is not yet verified. So the admissible answer is to request evidence and submit for approval, not to execute the payout. It denies the execution for payout of happens.

The payout tool may be available under Gate 1, but it is not admissible under Gate 2 for this case. This is exactly why Decision Governance matters. The problem is not whether the agent can act in general; the problem is what actions it is allowed to take now for this case, in this situation, within this context.

Admissibility is Not Only Constraint; It is Guidance

If agents are governed, it is not enough to say, “Here is a pool of admissible actions. Choose one.” That still leaves too much discretion with the agent. A governed system should determine what actions are admissible, what tools are admissible, what execution boundary applies, and what the next admissible action is in the current situation and context.

That means admissibility is not only a boundary; it is also guidance. So admissibility should determine, at runtime, what is allowed, what is not allowed, and what the next admissible step is. That is how governance becomes operational.

Beyond Admissibility: Best Admissible Action

There is another level after admissibility. Once the runtime determines what is admissible, the system should not simply leave the agent to choose freely from a pool of valid options. The next level is to determine the best admissible action.

“Best” here does not mean the most permissive action; it means the admissible action that maximizes outcome impact. That can be improved over time using feedback, success rates, downstream outcome quality, and business impact. So the progression becomes: Authorization → Admissibility → Best admissible action. That is how runtime control becomes outcome-driven, not just policy-driven.

Why This Also Matters for Security

This also aligns with current OWASP guidance for LLM and agentic systems. OWASP highlights risks such as excessive agency, improper output handling, sensitive information disclosure, and other failures that arise when systems allow models or agents to act too freely.

Those risks are not solved by identity or static permissions alone. For business actions, the answer must be resolved at runtime through an explicit business decision about what actions are allowed now for the case in its current situation and context. That is another reason admissibility belongs inside Decision Governance; it gives runtime control a business form instead of leaving it as scattered security and workflow fragments.

Why This Fits Microsoft’s Direction

Microsoft is already pointing to the need for runtime decisions before tools are invoked. Its security guidance frames the problem as runtime authorization beyond identity, and its Entra materials frame agent identities as purpose-built identity constructs for AI agents that need governance and authorization at enterprise scale.

That is the right trajectory. The next step for AI agents is to make that runtime answer explicit as admissibility, and the level after that is to move from any admissible action to the best admissible action.

Book a Custom Demo

Final Thought

Identity is necessary and runtime authorization is necessary, but for AI agents, they are still incomplete on their own. Enterprises need two gates:

Gate 1: Identity and Authorization – Who is the actor, and what is it generally allowed to access and use?
Gate 2: Admissibility and Control – Given this input, in this situation, within this context, what actions is this actor allowed to take now, and at runtime execution boundary deny, allow or differ (e.g. escelate).
Next level: Best admissible action – Within the admissible boundary, what action from the set of available actions should be chosen to maximize impact?

That is how runtime authorization becomes decision-centric.