What breaks when token handling and authorization are built into the model instead of the runtime?

Why the Control Plane Breaks When the Model Owns Authorization

Authorization works best when it is externalized from the model and enforced by the runtime or policy layer. The model can decide what it wants to do, but the runtime should decide what it is allowed to do, with per-action checks, scoped tokens, and auditable enforcement boundaries. Once the model starts handling token logic itself, the control plane becomes embedded in behavior that is harder to inspect, govern, and reproduce consistently.

That shift matters because model outputs are probabilistic and context-sensitive, while authorization needs stable, testable rules. If tokens or access decisions are assembled inside the model, teams lose a reliable place to enforce least privilege, separate duties, and prove that the same request is treated the same way every time.

runtime authorization also creates a cleaner boundary for integration design. In practice, that means the model can request an action, but a dedicated control layer evaluates the request against policy before any token is issued or reused. This is the point where least privilege, approval gates, and resource scoping stay enforceable instead of being expressed only in prompts or hidden tool instructions.

What Gets Harder to Govern in Practice

Token handling inside the model makes several operational problems more acute. Credential lifecycle events become less visible, because issuance, reuse, and expiration can be entangled with model prompts, tool calls, or intermediate reasoning rather than a managed identity workflow. Logging also fragments, since the evidence of who approved what, when, and under which policy can split across the model, orchestration code, and downstream services.

This is why practitioners usually prefer an external authorization layer with a clear policy decision point and policy enforcement point. NHIMG’s AI Agent Authorisation Guide is useful here because it frames per-action authorization, task-scoped access, and human approval as control design choices rather than prompt patterns.

The governance problem also gets worse at scale. A model that can shape or carry credentials can blur ownership between application engineering, security, and platform teams, which makes recertification, offboarding, and exception handling harder to track. NHIMG’s IAM and IGA Basics helps anchor the distinction between access policy, entitlement governance, and the lifecycle controls that should remain visible outside the model.

Why Prompt Injection Becomes an Access Problem, Not Just a Content Problem

When the model is allowed to handle authorization or token mediation, prompt injection can become a direct access path. The attacker is no longer trying only to influence text generation, but to influence the model into selecting a tool, forwarding a token, or widening access beyond the original intent. That turns a content integrity issue into an authorization failure.

For token-bound workflows, the safest pattern is to keep tokens away from the model and make access decisions per action in the runtime. If the model never sees reusable credentials, prompt manipulation has less room to convert into unauthorized API calls, cross-resource access, or silent privilege expansion. Externalized authorization also lets you constrain audience, action, and delegation more precisely than a general-purpose model prompt can.

NHIMG’s Authorisation Models Guide is a useful companion because it shows how RBAC, ABAC, ReBAC, and policy-based control support fine-grained decisions without embedding those decisions into the agent itself. For runtime token patterns, the IETF’s MCP authorization specification and RFC 8707: Resource Indicators for OAuth 2.0 both reinforce the same design idea, audience-bound tokens and resource-scoped access are easier to govern than token passthrough.

Risk and Threat Considerations

When authorization is embedded in the model, the biggest risk is that a single prompt compromise can alter both intent and access. That weakens auditability, increases the chance of overbroad token reuse, and makes it harder to prove whether an action was permitted by policy or merely produced by the model.

Failure mechanism: Prompt injection or adversarial context manipulation causes the model to emit, reuse, or forward credentials in ways the runtime cannot reliably constrain, so a text-level compromise becomes an access-level compromise.

Impact: Attackers can gain unauthorized API access, expand blast radius across tools or tenants, and leave incomplete logs that slow detection, response, and post-incident review.

Practitioner Guidance

What to prioritise: Keep authorization decisions in a runtime control layer, and treat the model as an untrusted requester rather than an access broker. If the model can affect credential issuance, audience, or reuse, move that responsibility out before expanding tool access.

What to verify: Confirm that every privileged action is checked at execution time, that tokens are audience-bound and short-lived where possible, and that logs show the policy decision, not just the model output. If you cannot reconstruct the decision path from logs, the control is too distributed.

Common mistake: Teams often harden prompts while leaving the access path unchanged. Prompt hardening may reduce abuse, but it does not replace a runtime policy boundary when the question is who can actually do what.

Practitioner takeaway: The key design choice is not whether the model can request access, but whether it can ever become the place where access is decided, because that is where auditability and least privilege usually fail first.

Related resources from NHI Mgmt Group

• What breaks when security teams rely on model output instead of verifying the authorization event?
• What breaks when AI observability is added after model and agent deployment instead of being built into the operating model?
• What breaks when organisations rely on JIT checkout instead of true runtime authorization?
• What breaks when delegation chains rely on token forwarding instead of explicit authorization?