Deterministic authorisation for AI agents is now a governance issue

At a glance

What this is: This is an analysis of why AI agent authorisation must be deterministic rather than classifier-led, using Claude Fable 5 as the prompt for a governance question about runtime control.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent action as an execution-time decision, not a post-hoc approval problem.

Context

AI agent authorisation is the decision layer that determines whether a runtime action should proceed, not whether the model is capable of proposing it. When the actor can choose a next step dynamically, governance has to move from static policy interpretation to explicit, auditable control at the moment of execution.

The article frames Claude Fable 5 as an example of how vulnerability discovery can become an API call, which turns the authorisation problem into one of control determinism rather than model output quality. That is a familiar identity pattern with a new actor type: the system still needs permissions, but the sequence and timing of actions are now decided at runtime.

For IAM teams, the key issue is not whether the agent is useful. It is whether the organisation can explain, constrain, and verify each delegated move before the agent executes it.

Key questions

Q: How should security teams implement authorization controls for AI agent tool calls in production environments?

A: Security teams should authorize tool calls at the point of execution, not merely trust a model-shaped instruction. The runtime needs evidence that a legitimate event occurred, such as a trusted model interaction or another verifiable source of authority. That boundary should be enforced in the dispatcher, with logging that preserves the call context, arguments, and execution state for later review.

Q: Why are probabilistic classifiers a problem for agent authorisation?

A: Probabilistic classifiers are a problem because authorisation needs repeatable decisions, not guesses about likely intent. If the same agent action can be approved one moment and denied the next based on score drift, organisations lose control consistency, which undermines auditability and weakens governance over privileged runtime behaviour.

Q: What breaks when an AI agent can choose its own attack path at runtime?

A: Static permissions and human-paced approval models break first. If an AI system can select actions, tools, and timing on its own, then access review no longer reflects real behaviour. Security teams need to govern the runtime decision loop, because the relevant risk is not only what the agent is allowed to do, but what it can decide to do next.

Q: How should organizations approach the governance of AI agents?

A: Organizations should adopt a governance framework that incorporates continuous visibility, adaptive IAM practices, and stringent policy-based controls. This ensures that all agent actions are tracked, authorized appropriately, and assessed for compliance.

Technical breakdown

Why probabilistic authorisation is weak for AI agents

Probabilistic authorisation uses a classifier, score, or policy suggestion to decide whether an action should proceed. That approach is tolerable when the request is simple and the subject is human-paced, but it becomes fragile when an AI agent can generate, chain, and retry actions at runtime. The governance problem is not just false positives or false negatives. It is that the approval path no longer maps cleanly to a single, stable intent. In autonomous systems, the action sequence itself can change while the policy engine is still evaluating the first request.

Practical implication: Treat probability scores as advisory signals, not the control plane for agent execution.

What in-loop authorisation means for agent identity

In-loop authorisation means the agent must ask for permission at the point of each meaningful action, with the decision enforced before the action executes. That differs from pre-authorising a broad task and hoping the runtime stays within bounds. For AI agents, this is the difference between a delegated objective and a governed execution path. If the agent can combine tools, retry failures, or branch into a different path, then the authorisation model must follow the runtime, not the original prompt. This is especially important where the agent touches APIs, secrets, or privileged workflows.

Practical implication: Place control decisions at each action boundary, not only at task start.

Deterministic policy as a governance requirement

Deterministic authorisation means the same inputs produce the same decision every time, with a traceable reason for allow or deny. That matters because agentic systems need repeatable control outcomes for audit, incident review, and containment. If one classifier says yes and another says maybe, the organisation cannot prove that the agent was governed consistently. This is not a model-quality debate. It is a control assurance issue. Determinism also makes it easier to align runtime behaviour with least privilege, because the policy can be inspected, tested, and versioned instead of inferred from probabilistic output.

Practical implication: Use deterministic policy logic for privileged agent actions and reserve classifiers for enrichment, not final approval.

NHI Mgmt Group analysis

Probabilistic approval layers create governance ambiguity, not assurance: When an AI agent can decide its next action at runtime, a score-based or classifier-led approval model cannot guarantee repeatable control outcomes. The same request can be treated differently depending on context drift, tool path, or model interpretation. That makes auditability weak and delegation boundaries hard to defend. Practitioners should read this as a control-design problem, not a model-risk footnote.

Runtime authorisation is the real control plane for agentic systems: The moment an agent can call tools, select actions, and choose timing without a human gate, the authorisation decision has to sit inside the execution loop. This changes the security objective from predicting behaviour to constraining behaviour. The implication for IAM and PAM teams is that governance must track the action itself, not just the identity that invoked it.

Deterministic policy is now the minimum viable assurance model: Agentic systems need allow and deny decisions that are consistent, explainable, and tied to explicit policy inputs. If the control path is probabilistic, accountability becomes contestable because the organisation cannot show why one action passed and another failed. For NHIMG, this is where AI agent governance meets classic identity discipline: runtime control must be precise enough to survive audit and incident review.

Least privilege changes meaning when the actor can choose its next move: Least privilege was designed for a stable subject with known task boundaries. That assumption weakens when the actor can branch into unplanned tool use, retry paths, or chained actions mid-session. The implication is not simply more policy. It is a different governance model for authorising action sequences rather than static entitlements.

Agent authorisation is becoming a distinct category of identity governance: The field can no longer treat AI agents as a variation of service accounts with a nicer interface. Their runtime behaviour forces a control model that is closer to execution-time policy enforcement than traditional request-based access management. Practitioners should expect this to pull identity architecture, API control, and audit design into one shared decision layer.

From our research library:

• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: Ultimate Guide to NHIs — Standards

What this signals

Deterministic agent governance: The next control gap is not whether organisations can block dangerous prompts, but whether they can make every agent action pass through an explicit decision boundary. When the actor can initiate its own execution path, the policy engine becomes part of the runtime, not a background checker.

Identity teams should expect AI agent governance to converge with API authorisation and privileged access design. The practical question will be how to keep runtime delegation explainable when the system can select tools and sequence actions faster than human review cycles can respond.

For practitioners

• Define action-level authorisation boundaries Map which agent actions require explicit pre-execution approval, which can be policy-authorised in-loop, and which must never be delegated to runtime discretion.
• Separate classifier output from final control decisions Use probabilistic detection or ranking only as advisory input, while the allow or deny decision remains deterministic and policy-based.
• Log every agent decision with policy context Capture the action requested, the policy inputs evaluated, the decision outcome, and the tool or API invoked so the control path is auditable.
• Reassess least privilege for runtime action chains Review whether current permission models assume a single task boundary when the real risk comes from chained tool use inside one session.

Key takeaways

• AI agent governance now depends on deterministic runtime authorisation, not on probabilistic confidence that a proposed action is safe.
• When an agent can choose its next move, static approval models stop describing the real execution risk.
• The practical control shift is toward action-level policy enforcement, auditable decisions, and bounded delegation for privileged workflows.

Key terms

• Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.
• In-Loop Authorization: In-loop authorization is a control pattern that evaluates an agent’s action at the moment it is about to happen. Instead of inspecting activity only after the fact, the system decides whether to allow, deny, or defer each action before execution, which is essential for local tools and fast-moving agent workflows.
• Session-Level Policy: Session-level policy is a rule set that applies only while a user, workload, or agent session is active. It governs actions such as access, step-up checks, time limits, and transaction approval. Technically, it evaluates context during an authenticated session and can change permissions without altering the underlying account or role.
• Probabilistic Approval Layer: A probabilistic approval layer uses model scores, classifiers, or confidence estimates to decide whether an action should proceed. In identity governance, that is useful for enrichment but weak as the final control point because it can vary across runs and is harder to audit.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.