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

Why This Matters for Security Teams

Security teams are not governing a static service account when they govern an AI agent. They are governing an autonomous entity that can chain tools, interpret prompts, and pursue a goal in ways that are hard to predict in advance. That is why traditional approval gates and role-based access alone are insufficient. Current guidance suggests treating agent behavior as a runtime risk problem, not just an onboarding problem, with policy decisions tied to intent, context, and live telemetry. The point is not to trust the model less, but to constrain the execution path more tightly as the agent acts. This framing is consistent with the OWASP OWASP Agentic AI Top 10 and NIST's NIST AI Risk Management Framework, both of which emphasize managing AI-specific risk at the system level. NHIMG research shows why this matters: in the SailPoint study on AI agents as the new attack surface, 80% of organisations said their agents had already performed actions beyond intended scope. In practice, many security teams encounter that drift only after unauthorized access or data exposure has already occurred, rather than through intentional design review.

How It Works in Practice

Runtime governance starts with workload identity, not just a password or static token. An agent should present cryptographic proof of what it is through a workload identity pattern such as SPIFFE, OIDC, or an equivalent machine identity control, then receive OWASP NHI Top 10 aligned privileges only for the current task. That means JIT credential provisioning, short-lived secrets, and automatic revocation on completion. It also means replacing broad RBAC grants with intent-based authorisation, where policy checks ask what the agent is trying to do, which data it needs, and whether the action is consistent with the current context. A practical operating model usually includes:

• Per-task credentials with narrow scope and short TTLs.
• Policy-as-code decisions evaluated at request time, not during annual review.
• Behavioral baselines that flag drift from the agent's named purpose.
• Step-up controls or quarantine when tool chaining exceeds expected patterns.
• Owner accountability so every agent maps to a human or service sponsor.

This approach is reinforced by the CSA MAESTRO agentic AI threat modeling framework and NIST's NIST Cybersecurity Framework 2.0, which both support continuous control, detection, and response. NHIMG's Analysis of Claude Code Security and AI LLM hijack breach coverage show the same pattern: once an agent can call tools and access secrets, the attack surface becomes operational rather than theoretical. These controls tend to break down when the agent is allowed long-lived credentials across many downstream tools because revocation and attribution become too slow to matter.

Common Variations and Edge Cases

Tighter runtime control often increases friction, so organisations must balance safety against latency, developer productivity, and workflow reliability. That tradeoff is real, especially in production agents that need to complete multi-step tasks without constant human approval. Best practice is evolving here, and there is no universal standard for every agent class yet. For low-risk assistants, organisations may accept broader guardrails and lighter telemetry; for agents with write access, financial authority, or customer data access, the case for JIT secrets and real-time policy evaluation is much stronger. Edge cases usually appear in environments with shared agents, multi-agent pipelines, or vendors that hide the underlying execution path. In those settings, static RBAC breaks down because one agent can inherit another agent's privileges, and a single human approver cannot accurately predict the full chain of actions. The strongest current guidance is to treat each autonomous component as a separate workload identity, then link them through policy and audit trails rather than shared credentials. NHIMG's Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references when auditability, ownership, and evidence retention matter as much as prevention. In practice, the hardest failures happen when an agent is allowed to improvise with stale credentials in a complex tool chain because no one notices the privilege path until after the action has been taken.

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 machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?