How should security teams model AI agents that can read, act, and delegate across systems?

Model them as non-human identities with multiple operational roles, then separate those roles by trust boundary and privilege scope. A single agent can behave like a user, a service, a datastore, and a tool caller in different paths. Security teams should therefore combine access review, workflow mapping, and layered threat modelling rather than assuming one architectural model covers everything.

Why This Matters for Security Teams

AI agents that can read, act, and delegate across systems do not fit neatly into the old “application account” model. They may inspect tickets, call APIs, write records, trigger workflows, and hand off tasks to other agents or services. That means one design choice can create a privilege path across multiple trust boundaries, which is exactly why NHIMG treats these systems as non-human identities with dynamic roles rather than as simple automation.

The practical risk is not just overprivilege. It is also role confusion, where an agent is trusted to retrieve context in one system and then reuse that context to act somewhere else without a fresh authorization check. Guidance from the NIST AI Risk Management Framework supports a lifecycle view of AI governance, but security teams still need to translate that into concrete control boundaries, identity records, and human approval points.

In practice, many security teams encounter agentic risk only after an incident review shows the agent had already crossed three systems and two approval assumptions, rather than through intentional design-time threat modelling.

How It Works in Practice

Security teams should model each agent around the functions it can perform, not around a single label. A useful starting point is to map four distinct modes: read, decide, act, and delegate. Read covers retrieval and context gathering. Decide covers inference or policy selection. Act covers tool invocation, API calls, and record changes. Delegate covers assigning work to another agent, a queue, or a human approver. Each mode should have its own trust boundary, logging requirement, and privilege scope.

This approach aligns well with the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix, because both push teams to think about attack paths, prompt manipulation, tool abuse, and delegated authority. In operational terms, that means:

• Assign a distinct identity or credential set to each agent role where possible.
• Separate read-only context access from write or execution privileges.
• Require step-up approval for high-impact actions such as payment, deletion, or external communication.
• Log prompts, tool calls, outputs, and delegation events as separate audit artifacts.
• Review which downstream systems trust the agent’s output as an input to their own logic.

Threat modelling should also ask where the agent gets its context and whether that context can be poisoned. If the model can retrieve tickets, documents, or web content, then retrieval integrity becomes part of the security boundary, not just data quality. Teams using CSA MAESTRO agentic AI threat modeling framework or NIST AI Risk Management Framework can translate those concepts into governance, mapping, measurement, and ongoing monitoring.

These controls tend to break down when one agent is given broad orchestration rights across legacy systems that cannot express per-action authorization or produce reliable audit logs.

Common Variations and Edge Cases

Tighter privilege separation often increases engineering overhead, requiring organisations to balance operational speed against stronger containment. That tradeoff is especially sharp in environments where agents are expected to coordinate across SaaS, internal APIs, and human approval workflows in near real time.

One common edge case is the “helper agent” that seems low risk because it only summarizes or routes work, but can still become a delegate path into sensitive systems. Another is the autonomous agent embedded in a business process where a human reviewer assumes final control, while the agent silently prepopulates actions that are rarely challenged. Current guidance suggests treating these as separate privilege domains, but there is no universal standard for how many domains are enough.

Agentic systems also change risk when they chain across vendors. A retrieval agent, a drafting agent, and a transaction agent may each look safe in isolation, yet together create an end-to-end workflow that bypasses intended checks. That is why the important question is not “what is the agent?” but “what exact actions can this identity take, under what conditions, and what downstream systems trust its output?”

For more mature programs, the control model should also reflect detection and response. Teams should be able to identify unusual delegation patterns, unexpected tool use, and sudden expansion in action scope. Where an environment has highly dynamic business logic, brittle integration layers, or poor identity hygiene, the model becomes much harder to sustain and the risk of invisible privilege escalation rises quickly.

Related resources from NHI Mgmt Group

• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?