How do organisations decide which controls belong on AI agents?

Why This Matters for Security Teams

Organisations do not decide control scope by asking whether an AI system is “smart”; they decide it by asking whether the system can act independently, change tool use at runtime, or expose the enterprise to downstream actions that are hard to predict. That shift matters because static IAM assumptions break quickly when an agent can chain tools, call APIs, and continue operating after the original prompt has moved on. Guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, not just inventory and approval at build time.

NHIMG research on the AI agents: the new attack surface report shows why this matters operationally: 80% of organisations say their AI agents have already performed actions beyond intended scope, while only 52% can track and audit the data those agents access. That gap is the practical reason control selection must begin with behaviour, privilege, and observability rather than product category. In practice, many security teams encounter agent overreach only after sensitive data has already been touched or exfiltrated, rather than through intentional control design.

How It Works in Practice

The cleanest way to classify controls is to separate fixed automation from autonomous action. If the system follows a pre-scripted workflow with no runtime discretion, standard NHI controls such as secret rotation, least privilege, and service account review may be enough. If the system can choose tools, alter plans, or continue acting based on intermediate results, it should be treated as an agent with delegated authority that needs stronger session controls, task scoping, and event-level auditability.

That usually means organisations implement controls in layers:

• Workload identity: bind the agent to a cryptographic workload identity such as SPIFFE/SPIRE or OIDC-based workload tokens so the system proves what it is before it receives any access.

• JIT authorisation: issue short-lived credentials per task, not long-lived secrets, and revoke them when the job ends or the context changes.

• Context-aware policy: evaluate each request at runtime using policy-as-code, such as OPA or Cedar, instead of relying only on a static role matrix.

• Session oversight: log tool calls, data access, prompt changes, and exception paths so the agent’s chain of actions can be reconstructed after the fact.

This is where OWASP NHI Top 10 becomes useful alongside the CSA MAESTRO agentic AI threat modeling framework: both push teams to map trust decisions to actual runtime behaviour, not to a job title or application label. The practical outcome is a control set that changes with the agent’s autonomy, the sensitivity of the target system, and the blast radius of the tools it can invoke. These controls tend to break down when agents share broad service accounts across multiple workflows because attribution, revocation, and scope enforcement all become ambiguous.

Common Variations and Edge Cases

Tighter control placement often increases operational overhead, requiring organisations to balance faster agent delivery against stronger review, monitoring, and revocation processes. That tradeoff is real, especially when teams want the flexibility of autonomous systems without the cost of per-task governance. Current guidance suggests there is no universal standard for this yet, so classification should be based on the highest-risk capability the agent can exercise, not the most benign use case.

One common edge case is the “assistive” agent that starts as a read-only helper but later gains write access, can trigger workflows, or can call external tools. Once that happens, it no longer fits a lightweight NHI model. Another is the multi-agent pipeline, where one agent may not appear risky in isolation, but the sequence creates emergent privilege escalation or data leakage. That is why control scoping must follow the entire action chain, not a single prompt-response pair.

NHIMG’s Ultimate Guide to NHIs — Standards is helpful here because it reinforces that classification should drive governance depth. Where the agent touches regulated data, production infrastructure, or credential-bearing systems, controls should usually include stronger approval gates, tighter TTLs, and explicit human override paths. Where it only drafts content or prepares recommendations, the organisation may still need logging and accountability, but not the same level of delegated authority control. The key exception is any system that can self-initiate actions after a trigger, because that usually pushes it into the agent control category even if the business initially marketed it as simple automation.

Related resources from NHI Mgmt Group

• Should organisations use security skill prompts instead of access controls for AI agents?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• What should organisations do when AI agents become part of the fraud problem?