AI application security needs runtime authorization, not just testing

At a glance

What this is: This analysis says AI application security has to move from pre-release testing and live filtering to a governed lifecycle that can discover, evaluate, authorize and prove agent behaviour in production.

Why it matters: It matters because IAM, PAM and AI governance teams now have to decide who or what can authorize an agent’s consequential action, and how that decision is evidenced after the fact.

Context

AI application security is no longer just about model quality or content filtering. Once an agent can take action in production, the security question becomes whether the organisation can govern discovery, testing, runtime authorization and evidence for what that agent actually did.

The governance gap is that many current control models are still built around pre-release assurance or after-the-fact detection. For AI agents, that is too late if the consequential action is already proposed, dispatched or delegated under a policy the business cannot verify.

This article frames the problem as a lifecycle issue across AI systems, tools, data connections and delegated authorities. That makes it relevant to identity security because the real control point is not the model alone, but the authority granted to the system that acts on its behalf.

Key questions

Q: What breaks when AI automation is allowed to act outside defined policy boundaries?

A: When AI automation exceeds policy boundaries, the main failures are uncontrolled response actions, excessive data access, and loss of operator trust. In security operations, that can mean false containment, inappropriate file or account isolation, and difficult-to-audit decisions. Strong guardrails prevent the agent from becoming a hidden execution layer that changes the security posture without oversight.

Q: Why do AI agents change IAM and PAM assumptions?

A: AI agents change IAM and PAM assumptions because they can act continuously, use tools directly, and execute without the human pacing that traditional review cycles expect. That makes static entitlements, delayed approvals, and post-hoc certification weaker controls. The programme has to govern runtime use, not just the assignment of access.

Q: How do security teams know whether an AI agent control stack is actually working?

A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.

Q: What should teams do when agents can delegate work without human approval?

A: Teams should place controls at the delegation boundary and require explicit policy for which agents may call, hand off to, or consume output from other agents. Without that governance, approval-free delegation turns routine orchestration into uncontrolled downstream action.

Technical breakdown

Discovery and inventory for AI agents, tools and delegated authority

Discovery is the first control plane because security cannot be applied to systems the organisation cannot enumerate. In this model, inventory covers agent frameworks, MCP servers, tool surfaces, local runtimes, environment-file API keys, vector stores and the data paths reachable from code. The important detail is that discovery is read-only and honest about blind spots. A scan that fails should report incompleteness rather than produce false assurance. For practitioners, inventory is not the outcome; it is the dataset that later stages consume when deciding what is allowed to execute.

Practical implication: Treat incomplete AI inventory as a governance failure, not a tooling nuisance, and block policy rollout until discovery gaps are visible.

Runtime authorization is the control point, not post-event detection

The article distinguishes runtime authorization from monitoring. A control that watches a tool call after dispatch can explain what happened, but it cannot stop the side effect. The useful control sits on the path between the agent’s proposed action and execution, evaluates the concrete request, and returns permit, mask, deny or approval required. That means the decision includes the actor, action class, target, credentials and delegation context, not just the prompt text. This is where AI application security intersects with IAM and PAM: authority must be decided before the action becomes reality.

Practical implication: Put policy enforcement on the dispatch path so consequential agent actions are decided before execution, not reconstructed after the event.

Evidence and verifiability in AI governance

Evidence is the last stage because governance only matters if a third party can prove what was tested, permitted, denied or escalated. The article describes signed receipts, policy-version binding, tamper-evident batching and offline verification as the mechanism that turns runtime decisions into audit-ready proof. That matters because a dashboard is not evidence. If the organisation cannot independently verify the decision trail, then the control is still partly a trust exercise. For IAM and compliance teams, verifiable evidence is what connects operational enforcement to auditability.

Practical implication: Require machine-verifiable decision records for agent actions so auditors can confirm policy enforcement without relying on vendor assertions.

Threat narrative

Attacker objective: The objective is to get a production agent to carry out consequential actions that exceed its intended authority while leaving no independently verifiable approval trail.

1. Entry occurs when an agent is given broad access to tools, data connections or delegated authority without a verified control point for each consequential action.
2. Escalation happens when the agent can propose or dispatch actions that exceed the intent of the original task, especially through tool calls, delegation or over-broad arguments.
3. Impact follows when the organisation cannot prove what was allowed, masked, denied or approved before the side effect occurred, leaving the action ungoverned and non-repudiable.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI application security is becoming a runtime governance problem, not a model assurance problem. Testing before release and filtering after launch do not answer the controlling question once an agent can act in production. The control point shifts to the moment a proposed action meets policy and evidence requirements, which is where identity, authorization and auditability converge. Practitioners should treat the runtime decision as the new centre of gravity.

Access review processes assume access persists long enough to be reviewed; agentic behaviour breaks that assumption. If the system can acquire authority, act and delegate within the same operational window, there may be no stable state to certify after the fact. That is an assumption collapse, not just a control gap. The implication is that governance has to move from periodic review toward pre-action authorization and verifiable decisioning.

Identity governance for AI agents now needs the same discipline that IAM and PAM apply to humans and workloads. The article shows that tool surfaces, delegated authority and execution context are part of the identity problem, not adjacent to it. That places AI application security inside lifecycle governance, where authority must be inventoried, constrained, reviewed and evidenced. Security teams should stop treating the agent as a special case and govern it as an identity-bearing system.

Verifiable evidence becomes the difference between security control and security theatre. A runtime policy that cannot be independently checked is still a trust statement, not a control. The most durable programmes will be the ones that can prove what was evaluated, what was permitted and what was denied without calling the vendor. Practitioners should demand decision artefacts that survive audit and incident review.

Runtime authorization boundary: AI security only becomes governable when the decision point is on the path to execution and tied to a signed record. That named control boundary is the article’s real contribution. It clarifies that discovery, testing and red teaming are necessary, but they do not replace a dispatch-path policy engine. Teams should design for control-plane evidence, not dashboard evidence.

What this signals

Runtime authorization is the control boundary that changes AI security from observation to governance. Organisations should expect their current review cycles to miss agent actions that begin and complete within a single task. That means the design problem is now policy enforcement on the execution path, not another layer of alerting after the fact.

Agent authority has to be managed like identity, not like generic application behaviour. The useful questions are who granted it, what it can touch, and how far delegation can propagate before a human or policy boundary intervenes. That is why AI governance, IAM and PAM are converging around the same operational problem.

Control evidence needs to be independent of the agent itself. If an AI system can claim it complied, but no external artefact can prove what the runtime decision was, the programme still depends on trust. Practitioners should prioritise decision receipts, policy versioning and verifiable execution records over post-hoc dashboards.

For practitioners

• Define the governed AI action path Map where an agent can propose, dispatch or delegate a consequential action, and distinguish those paths from monitoring-only paths that cannot block execution.
• Inventory delegated authority and tool surfaces Catalogue agent frameworks, MCP servers, exposed tools, environment-file keys and reachable data stores, then mark which paths are ungoverned, harnessed or governed.
• Enforce pre-execution authorization Require permit, mask, deny or approval-required decisions before the tool function runs, with the decision based on actor, target, operation class and delegation grant.
• Require verifiable decision receipts Capture signed records for every material runtime decision so auditors can reconstruct what was allowed, denied or escalated without trusting the agent.
• Re-test changed policies against real traffic Simulate new or edited rules against recent agent traffic in monitor mode before enforcement, and do not activate controls that would break legitimate work.

Key takeaways

• AI application security is shifting toward lifecycle governance because agents create risk at runtime, not just at model launch.
• The article’s core insight is that discovery, testing and red teaming are necessary but insufficient without a dispatch-path authorization control.
• Practical programmes will need verifiable decision records so auditors and security teams can prove what an agent was allowed to do.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Decision Receipt: A signed record of a control decision such as permit, deny, redact, or approve. It contains the canonical payload, hashes, signatures, and verification metadata needed to prove the record existed and remained intact after creation.
• Agentic Surface: The agentic surface is the set of connections, permissions, and actions available to an AI system that can initiate work, call tools, or trigger downstream processes. For governance, it is the point where a model stops being a text engine and starts becoming an access actor.

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 building or maturing an IAM programme, it is worth exploring.