How should security teams govern AI agents that can change actions at runtime?

Why This Matters for Security Teams

Runtime AI agents are not just another application workload. They can decide which tools to call, reorder steps, retry failed actions, and alter the path they take to complete a goal. That means the risk is not only who the agent can reach, but what it can choose to do once it has enough context. Static RBAC and long-lived secrets were built for predictable service accounts, not autonomous software with execution authority.

Current guidance increasingly points toward context-aware control planes that can evaluate intent, data sensitivity, and session state at request time. That aligns with the broader direction of the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework, both of which emphasise managing dynamic risk rather than trusting a single static permission grant.

NHIMG research shows why this matters operationally: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope. In practice, many security teams encounter agent misuse only after sensitive data has already been accessed or disclosed, rather than through intentional governance.

How It Works in Practice

Security teams should treat the agent as an identity-bearing workload that needs runtime governance, not a user proxy that gets broad standing access. The control model should combine workload identity, short-lived credentials, and policy evaluation that can inspect the current task before allowing any tool invocation. For many environments, that means using cryptographic workload identity such as SPIFFE or OIDC-backed tokens, then issuing just-in-time credentials only for the specific action path the agent is approved to take.

This is where static policy breaks down. A role can say the agent may access a database, but it cannot easily express whether the agent should read one record, summarize a report, or trigger a downstream payment workflow. Intent-based authorisation is the better fit: the policy engine evaluates the agent’s declared goal, the resource requested, the sensitivity of the data, and any prior actions in the session. That approach is consistent with the direction of CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework.

A practical runtime pattern usually includes:

• Ephemeral secrets with tight TTLs, issued per task and revoked at completion.
• Policy-as-code checks at each tool call, not just at login or initial orchestration.
• Data-scoped approvals that separate read, transform, and write actions.
• Audit logging that records intent, tool use, and data touched for every step.

That is especially important when agents can chain tools, call MCP-integrated services, or escalate from harmless retrieval into a high-impact workflow. The OWASP NHI Top 10 and Top 10 NHI Issues both reinforce that the identity layer, the secret layer, and the policy layer must be evaluated together. These controls tend to break down when legacy service accounts are reused for agents because the account inherits broad permissions that no runtime policy can safely narrow.

Common Variations and Edge Cases

Tighter runtime control often increases latency and operational overhead, requiring organisations to balance safer approvals against user-facing responsiveness. That tradeoff is real, especially in multi-agent systems where one agent may delegate to another, or where a tool chain needs several approvals in quick succession. Current guidance suggests using risk-tiered policy so low-impact read actions stay fast while high-impact write actions trigger stronger verification.

There is no universal standard for this yet, but best practice is evolving toward layered checks: workload identity at the transport layer, intent validation at the policy layer, and secrets issuance at the execution layer. In high-assurance environments, teams may also combine runtime controls with zero standing privilege, since persistent access is the hardest problem to defend once an agent can adapt its sequence mid-session. For deeper context on identity lifecycle and audit expectations, see Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

Edge cases usually appear when agents operate across SaaS, internal APIs, and human approval workflows at the same time. In those environments, intent can be clear to the orchestration layer but opaque to downstream systems, so the policy must be enforced as close to the action as possible. This becomes even more difficult when organisations cannot trace which data an agent accessed, a gap highlighted by NHIMG research and the broader concerns in the OWASP Top 10 for Agentic Applications 2026.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern AI agents that can take runtime response actions?
• How should security teams govern AI agents that can change behaviour at runtime?