Putting Agentic AI on a leash: Why companies need to set clear boundaries for autonomous AI

It sounds like a contradiction: Agentic AI is rapidly making its way into day-to-day work, automating tasks, preparing decisions, making them independently, and even putting them into action. But autonomous AI agents urgently need clear guardrails if companies want to maintain security. The more autonomously AI agents operate, the more important it becomes to ask how their access, permissions, and actions can actually be controlled. And honestly: can you answer that with confidence today?

From large language model to AI agent

Questioning the use of AI through the lens of identity security has been essential from day one. When it comes to large language models, or LLMs, the questions are often classic IAM questions: Who has user access? Which roles have been assigned? Which APIs and tools can access the model? So anyone looking to use language models for generating text, summarizing content, translating languages, writing code, or answering questions should start by getting clear answers to those questions.

The same also applies to retrieval-augmented generation, or RAG, which combines LLMs with an external knowledge source. Here, the model draws on additional information to generate the most likely output. One thing is important to keep in mind: both of these forms of AI operate in a static way. There is no “understanding” in the human sense.

But the next stage of evolution is already here: proactive AI agents. By combining LLMs with planning, memory, and interfaces to other tools, they can pursue defined goals and carry out actions. Prioritizing tasks, controlling systems, or automating multi-step workflows comes naturally to them. But that also opens the door to bypassing security barriers, as mistakes can be automated and decisions can be made autonomously outside the original system context.

The same is true of multi-agent systems, with one important difference: complexity increases even further, poor decisions can multiply, and control, traceability, and security are the ones that suffer.

Identities and access at risk

This makes the biggest difference from traditional applications clear: it is not the model itself that changes the game, but the layer of action. AI agents actively access systems, perform actions, and make decisions in the context of their tasks.

That means identity and access management has to account for additional dimensions. As soon as AI systems no longer just generate content but independently access tools, interfaces, and data, control over identities, permissions, and chains of delegation moves to the center of the conversation. “Who is using AI?” is replaced by questions like these:

• Under which identity is the agent acting?
• On whose behalf is it acting?
• What task is the agent expected to perform?
• Which rights have been delegated to it?
• Where do those rights need to be limited?
• How can the decisions and actions of AI agents remain traceable?
• Who is ultimately accountable for what the AI agent does?

What changes with AI agents

Put simply, security shifts from “What is the user allowed to do?” to “What is the agent allowed to do in the context of the user?”

Where humans used to hold decision-making authority, the AI agent increasingly takes over and then executes directly. Individual prompts and isolated AI responses give way to multi-step chains of actions carried out automatically. A clearly defined principal, whether user or service, no longer exists in the same way. In its place is a hybrid principal that performs a task on behalf of a user via an LLM.

The consequences are significant. A scope that was once known and static expands dynamically through tool calls. Visible, local errors may decrease because there is less direct human interaction with the AI. At the same time, however, errors propagated through action chains increase. Once agentic AI is in play, it becomes much harder to reconstruct who did what.

A dangerous misconception: flawed assumptions about AI agents

Given these risks, companies urgently need to clear up some common misunderstandings. Many false assumptions are still circulating, and they lead to IAM being implemented in ways that are not secure. If any of the following statements sound familiar, action is needed.

• We already have roles and tokens in place. Existing IAM models are built around users and services and provide a solid foundation for securing them. But autonomous agents that act on behalf of both, accumulate context, and make decisions are still missing from most models even though they need to be included if companies want meaningful control.

• An agent is just a prompt. Definitely not. A prompt has no persistence, no memory, and no tools. An AI agent, by contrast, has session state, long-term memory, and real OS- or API-level access. That requires additional protective controls.

• Our existing monitoring at the LLM level is enough. LLMs only ever see tokens. How an AI agent works with those tokens, which APIs it calls, which data it reads, and which decisions it makes all happens outside the LLM’s direct context.

• AI agents are independent actors. The EU AI Act is clear on this point: AI agents are not considered independent actors. What is required instead is traceability back to a person. Every action taken by an agent must therefore be attributable to human responsibility and legal ownership. Governance principles are essential as a result.

At the end of the day, this means the very things required to operate AI agents securely are often missing: transparency into their identity, control over their permissions, and traceability of their actions.

Thinking one step further: guardrails for agentic AI

So what do companies need to do now? They need to rethink how control, accountability, and security are organized. One thing is becoming increasingly clear: traditional security models cannot simply be applied to AI agents. New guardrails are needed technically, organizationally, and conceptually. Seven aspects are foundational.

1. AI agents need their own identity

AI agents are not ordinary user accounts or technical service accounts, and they should not be treated as such. Because they access systems independently, process context, and make decisions, they need their own identity model with clear ownership, a defined lifecycle, and traceable permissions. Only once it is clear under which identity an agent is acting can its behavior be meaningfully controlled.

2. Permissions need to be narrower and more context-aware

The degree of autonomy matters here. The more autonomously an agent acts, the more dangerous broad or permanently overprovisioned permissions become. Companies should therefore move away from blanket access rights and assign permissions that are task-specific, time-limited, and tightly scoped. AI agents, too, should only be able to do what is necessary for a defined purpose. That is the only way to prevent delegated access from quietly turning into unnecessary privilege expansion.

3. Authorization checks need to be tighter and dynamic

The identity-related challenges posed by AI agents extend directly into access management. That means access needs to be checked and enforced in a much more fine-grained, context-sensitive way.

Is the agent allowed to make this API call in this context? Can it modify that file, or only read it? Is this action even part of the task it is currently supposed to perform? Does the delegating user actually have the right they are passing on to the agent?

These questions cannot be answered only once during setup. They need to be answered continuously, at runtime. AI agents operate dynamically: their context changes, their tool calls are not always predictable, and their action chains can extend into areas that were never intended at the outset.

Static rule sets are not enough. What is needed now is a consistent zero-trust model: no agent is trusted automatically, neither because of where it comes from nor because it was approved once. Every action needs to be evaluated again. Technically, that requires fine-grained external authorization mechanisms, in other words, authorization engines that make access decisions centrally, rule-based, and context-aware, rather than embedding that logic in the agent itself or in the target system. The principle of least privilege must be applied rigorously to every single step in the agent workflow, not just to the initial entry point.

But technology alone is not enough. Alongside the question of what an agent is allowed to do comes another immediate question: who is accountable for it?

4. Accountability needs to be clearly assigned

Autonomy must never result in blurred responsibility across the organization. For every AI agent, it should be clearly defined who sets its purpose, who operates it technically, and who is responsible for how it is used. This organizational clarity is important not only for governance, but also for liability, compliance, and secure operations. Without clearly assigned owners, blind spots emerge and security gaps become more likely.

5. Traceability has to go beyond traditional logs

Logging access events is not enough when AI agents are involved. Organizations need to be able to understand at any time why an agent acted the way it did. For many companies, the EU AI Act makes exactly this a regulatory requirement. Traceability is therefore not a nice-to-have. It is a compliance requirement. Only this broader form of transparency creates the basis for effective controls, reliable audits, and proper forensic analysis when something goes wrong. In other words, technical logging has to become true decision traceability.

6. Critical actions need hard control points

Not every AI agent decision should run fully automated from start to finish. Especially when sensitive data access, far-reaching changes, or financially or regulatorily significant processes are involved, defined control points are needed, with a clear human in the loop. Human approval is not a step backward for automation. It is deliberate security design. That includes central policy enforcement points, the ability to intervene immediately, and human approvals for especially critical steps. Security architecture therefore needs to be designed so that agents can work productively without ever escaping oversight.

7. AI agents need to be embedded into existing incident response processes

If an AI agent moves outside its defined scope of responsibility, that has to be detected and isolated immediately. A real example that sounds harmless makes the point: a telesales AI agent is asked by a caller to read out a cookie recipe on the spot. It happily complies. No immediate damage is done, but it is still a fundamental failure of control. Who guarantees that the same agent would not also comply with more sensitive requests?

Behavior like this has to be uncovered and addressed consistently. Companies need the technical ability to detect anomalies in agent behavior in real time. Clear playbooks for incident scenarios are essential here: who intervenes, and when? How are sessions terminated, permissions revoked, and action chains reconstructed? Incident response for AI agents is not optional. It is the last line of defense.

Autonomy needs control

Companies adopting AI agents today can certainly benefit from meaningful relief in day-to-day work. But potential alone is not a security concept. As autonomy increases, the security question shifts. It is no longer just about who has access, but also about who is acting, on whose behalf, and with what scope. Connecting identities, permissions, and accountability through clear guardrails is what lays the foundation for using agentic AI securely and in a controlled way. Only then can potential and security truly go hand in hand.

Looking to use AI agents in a controlled way? We would be happy to support you on the path to IAM that is ready for agentic AI.

Book a meeting now