How should security teams govern AI agents that can change behaviour based on prompt context?

Treat the agent as a runtime identity, not a fixed script. The control goal is to limit how untrusted context can change tool use, output shape, and execution path. That means separating instructions from user data, constraining outputs into structured fields, and validating every tool boundary before the agent can act.

Why This Matters for Security Teams

AI agents do not just consume identity, they exercise it. When prompt context can alter tool choice, execution order, or data exposure, static IAM assumptions stop holding. That is why security teams should treat these systems as autonomous workloads with changing intent, not as fixed application code. Current guidance is converging on context-aware controls, but there is no universal standard for this yet. The practical baseline is to reduce standing trust and make every action prove its purpose at runtime, as described in OWASP Agentic AI Top 10 and NIST AI Risk Management Framework.

That matters because prompt injection, tool misuse, and context poisoning can shift an agent from a helpful assistant into a privileged operator in one interaction. NHIMG research on the OWASP NHI Top 10 maps this directly to agentic runtime risk, while the SailPoint report shows 80% of organisations have already seen agents act beyond intended scope. In practice, many security teams encounter agent misuse only after a tool call, data spill, or unexpected workflow completion has already occurred, rather than through intentional design review.

How It Works in Practice

The control model should start with workload identity, not user-like roles. Give the agent a cryptographic identity that can be evaluated at request time, then bind access to the task, the context, and the destination system. That usually means short-lived credentials, ephemeral secrets, and policy decisions that are recalculated per action rather than inherited for the whole session. For implementation direction, CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both support this move toward runtime governance.

A workable pattern is to separate the agent into four control layers:

• Identity: issue a workload identity to the agent runtime, not a shared service account.
• Authorisation: evaluate intent-based rules before each tool call, with context such as task, sensitivity, and destination.
• Secrets: mint JIT credentials per task and revoke them automatically when the task ends.
• Execution: constrain outputs into structured fields so the model cannot smuggle instructions into tool parameters.

That approach aligns with NHIMG guidance in the AI LLM hijack breach analysis and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where agents chain tools or request new permissions mid-workflow. These controls tend to break down when the agent must operate across multiple loosely governed tools that do not support per-request policy evaluation.

Common Variations and Edge Cases

Tighter runtime control often increases latency and integration overhead, so organisations have to balance safety against throughput and developer friction. That tradeoff is especially visible in multi-agent systems, where one agent delegates to another and each hop needs its own identity proof and policy check. Best practice is evolving, not settled, but the direction is clear: use zero standing privilege, time-boxed secrets, and explicit allowlists for tool use instead of broad role grants.

One edge case is long-running agents that need continuity across multiple steps. In those environments, the safest pattern is not a long-lived token, but a renewable session with narrow scope and audit logging at each renewal point. Another is context-heavy agents that work with untrusted documents or chats; prompt content should never be allowed to redefine tool authority. For broader governance and audit expectations, see Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives, alongside NIST Cybersecurity Framework 2.0 for control mapping. The guidance breaks down fastest when teams treat agent behaviour as predictable enough for static RBAC, because the agent can still pivot from one approved task to another high-risk action through context alone.

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 change behaviour at runtime?
• How should security teams govern machine identity credentials in agentic AI environments?