When AI acts: access control and identity access management

A good agent identity not only answers the question “Who is this?” but also three questions that are usually answered implicitly in human identities:

1. Who is responsible (owner)?
2. How long is the identity valid (expiry)?
3. On whose behalf is the agent acting (delegation)?

Just as an employee has a user account with defined attributes, the AI agent receives their own, complete profile. The following example illustrates an agent identity in the directory service:

The well-known basic principle of least privilege also applies to AI agents, but needs to be rethought in order to do justice to the modern hybrid practical reality between humans and machines.

Least privilege follows the principle that each entity no longer receives only the permissions that it absolutely needs for a specific task. In the case of human users or traditional system accounts, this is a largely solved discipline. In the case of AI agents, this model fails in its classic form because three basic assumptions no longer apply:

• Tasks cannot be predicted. An agent often receives broad instructions and decides for themself which tools they want to use for this purpose.
• Permissions are not a binary decision. An agent who is allowed to read e-mails may also be able to send, forward, or delete, depending on API granularity.
• Context dynamically changes needs. What an agent needs in task A is irrelevant in task B, but the permission remains.

A) Task-based instead of role-based permissions 
Classic IAM assigns roles (e.g. HR Manager). For AI agents, a task-based approach is more effective: the agent receives only the permissions that are necessary for the specific, current task and these will expire automatically after completion. 

Instead of: agent has permanent read access to all financial data 
Better: agent receives read access to invoices from Q2 2026 for Task X; valid for 15 minutes. 

B) Scoped tokens instead of permanent API keys 
Broad scope API keys are the equivalent of a master key. Instead, short-lived, narrowly limited tokens should be used for AI agents analogous to OAuth scopes, but defined more granularly at the resource level. 

C) Tool-level permissions
Each tool available to an agent should be released individually and explicitly, not as a package. As a rule of thumb: if a tool is not absolutely required for the defined application scenario, it is unavailable. 

D) Hierarchical agent permissions in multi-agent architectures 
If an orchestrator agent coordinates several sub-agents, no sub-agent may have more privileges than the orchestrator themself has ( see Part 1 of this series). Permissions can be delegated, but never escalated. This principle is referred to in the literature as privilege containment.

The short answer is: no, not automatically. Only if the architecture explicitly forces this. 

This is an important point that CISOs shouldn’t sugar-coat: complete traceability is not something AI agents bring with them on their own. It is an architectural decision that must be actively implemented. Without these precautions, three gaps typically arise: 

1. Delegation chains disappear. Agent A engages Agent B, who engages Agent C – if not every transfer is explicitly logged, the only thing that remains visible at the end is that something happened, not why and on whose original request. An agent does not simply act on behalf of a defined unit, but receives one delegated authorization per action.

2. Reasoning is not deterministic. Two identical requests can lead to different actions. The question “Why did the agent make that decision?” can often only be reproduced via the logged intermediate steps (reasoning trace), but neither reliably nor precisely.

3. Third-party tools are black boxes. As soon as an agent calls up an external API or SaaS tool, their own visibility ends at the reporting boundary.

Traceability is thus possible, but only with explicit control points along the entire chain (delegation chain). The fact is that without clean architecture, the use of AI agents quickly becomes a forensic scavenger hunt, which can become expensive. 

Precisely because Agentic AI makes decisions autonomously, uses tools and interacts with peripheral systems, decision and action provenance is needed: every relevant action must be technically, organisationally and professionally traceable. This also fits in with the zero trust approach, where every access is checked, as well as with AI governance and TRiSM approaches, which require monitoring, traceability, data and risk control. 

While the factors 2-4 described above contribute to prevention, the factor of accountability provides the visibility without which least privilege, context and continuous verification would remain “blind”. A preventive effect of accountability arises as soon as it is coupled with real-time evaluation. This transforms the pure documentation into a trigger for automatic countermeasures. 

This is where SIEM/XDR comes into play – as a link that turns detective accountability into reactive, partly preventive control and places agent actions in the SOC field of view. Not as exotic AI logs in some side room, but rather integrated into: SIEM, SOAR, XDR, IAM, DLP, ERP audit logs, API gateway logs, CASB/SASE context. SIEM (log correlation) and XDR (cross-system detection and response) are the layers that weave a coherent picture from individual audit trails and derive actions from them. 

Specifically, these are the following four parameters: 

A) Correlation across reporting boundaries
A single agent access to system A looks harmless. Only when SIEM detects that the same agent is accessing system A, then B, then C within 90 seconds, i.e. systems that have nothing to do with each other, does a pattern of “lateral movement” occur. This correlation is exactly what makes the delegation chain and the individual agent logs evaluable in the first place.  

B) Behavioural baselining for agents
XDR learns the normal behaviour of an agent: What systems does a specific agent typically address? At what frequency? At what times? If the behaviour deviates (such as accessing a financial system that never appeared in the normal profile), the system triggers. This is anomaly detection applied to non-human identities. 

C) Automatic response as a preventive lever
This is where the transformation takes place, away from something that has been recognised to something that is prevented. Defined playbooks can take effect immediately if lateral movement is detected, for example: 

• Immediately invalidate agent’s token 
• Isolate/quarantine agent session 
• Temporarily block affected systems for this agent ID 
• Trigger human escalation 
   

The key point: this automated response happens in seconds, i.e. while the incident is running, not hours later during the log evaluation. This prevents any further lateral movement, even if the first movement has already taken place. Spreading is prevented and the blast radius is effectively contained. 

D) Effect on least privilege, context and continuous verification
SIEM/XDR insights flow back into the policy engine: an agent that has acted conspicuously can automatically be subjected to stricter continuous verification rules or be downgraded in their privileges (least privilege). This closes the loop between detective and preventive control. 

In terms of architecture, this means: accountability logs are worthless if they are only written into an archive that nobody evaluates in real time. The value is only created during coupling. The agents’ audit traces must flow natively and in a structured manner into the SIEM/XDR pipeline, with agent ID, delegation chain and context as correlating fields. Only then does “We find out who it was afterwards” become “We stop it while it is happening.” 

What this means for you in your role as CISO 
The least privilege principle remains correct – but it must be operationalised for AI agents. 
Three measures with immediate effect: 

1. Introduce just-in-time access:  permissions are issued on demand for a defined period and scope and then automatically withdrawn.
2. Establish 3Agent Identity Registry:  each AI agent receives their own unique identity in the directory service – with defined permissions, owner and review cycle.
3. Establish permission audits for agents as a regular process: not annually, but every time an agent’s job profile changes. .

In principle, the aim should not be to restrict the permissions of AI agents, but to ensure the smallest possible area of attack with maximum functionality. Is this a question of security philosophy? No. It’s a question of system architecture. So the key guiding question is no longer: “What permissions does an AI agent need?” but rather: “What level of trust does this agent get for which task and under which conditions?” 

This results in a modern calculation model with five core principles, which can be summarised as a structural guide in the following formula: 
Identity × least privilege × context × continuous verification × accountability = controlled ability of AI agents to act 

The multiplicative logic between the arc of “Who → What → Why → Still valid? → Who is liable” illustrates that a single neglected factor sets the overall level of security to zero. An AI agent can be perfectly identified, given minimum permissions, and be fully verified according to the context. If no responsibility can be assigned in the event of a claim (accountability = 0), the entire model is worthless where governance is concerned. 

The core principles in a nutshell:  

1. Identity first: each agent has a unique identity. 
2. Least Privilege: minimal, task-related rights instead of blanket access. . 
3. Context: permissions change depending on the situation, risk and purpose. .
4. Continuous Verification: this is the zero trust anchor, which means that every action is reviewed and authorised on an ongoing basis. .
5. Full Accountability: every decision and every action taken by an agent is traceable and assigned to a responsible office..

This model follows the zero-trust security approach and works well with current concepts such as Agent Identity, AI Governance and AI TRiSM (AI Trust, Risk and Security Management), which are increasingly establishing themselves as a reference for the secure use of agent AI.

The following best practices serve as guidelines in the IAM for AI agents: 

• Human-in-the-loop (HITL): critical actions (e.g. sending quotes or contract amendments) should be approved prior to execution by human employees. 
• Use of AI gateways: use standardised interfaces and gateways (e.g. AI gateways) to monitor and log AI access.