Dies ist die vollständige englische Fassung dieses Beitrags. Zur deutschen Kurzfassung
When people talk about securing AI agents, the conversation tends to start with the model and whether it can be manipulated or pushed beyond its instructions.
Those are fair questions, but a good prompt is not a security control. Once an agent is allowed to act, the more interesting security problem starts with what happens next and how far that action can travel through the systems around it.
Take an agent processing a supplier invoice. It checks the master data and prepares the payment. If it spots a discrepancy, perhaps it is even allowed to update the bank details before continuing. Nothing about those individual steps has to look suspicious, yet the money can still end up in the wrong account.
Nobody needs to have hacked an API for that to happen. The agent may simply be acting on bad or manipulated context while having enough legitimate authority to complete the transaction.
That is what I mean by the chain of action. A goal leads to tool use, which leads to access and often brings more context into the process. What happens at one stage influences what becomes possible at the next. The risk therefore lies not only in the individual systems, but in the way they connect and allow the action to continue.
Knowing the agent is only the first step
An agent needs a reliable identity, particularly once it starts delegating work to other agents, workloads or services. Without that, it quickly becomes difficult to work out who actually initiated an action and on whose behalf it happened.
But identity only answers part of the question. Knowing which agent is knocking does not tell you whether that agent should be allowed to change supplier data or initiate a payment in the situation it is in right now.
Identity tells us who the agent is. Authorisation has to deal with what it is allowed to do in the current context.
A lot of access models still make that decision too early and too broadly. A token gets issued and gives access to several functions of a service, even though the agent may only need one of them for the job in front of it. That may be acceptable for a tightly controlled application flow, but it becomes much harder to justify when the agent can choose its own next step.
Authorisation therefore needs to stay closer to the action. If the task changes or the agent moves to a different target, the authority behind it should be reassessed rather than simply carried forward.
The same applies when one token is exchanged for another. The new token should not quietly gain authority that was never part of the original grant. And short-lived does not automatically mean safe. A credential that exists for only five minutes can still do a lot of damage if it carries too much authority during those five minutes.
That is why continuous authorisation matters. It keeps asking whether the authority still fits what is happening now.
Secure the Chain
Securing the chain does not mean stopping an agent before every action. It still needs enough freedom to complete the task it was given. The important point is that its authority should match what it is trying to do, rather than giving it broad access simply because that might be useful later.
The same principle applies to context. An agent needs enough information to make a useful decision, but that does not mean it should automatically receive everything the surrounding system knows. Nor should it carry a broad standing credential when a more limited token for the target system would be enough.
This becomes especially important when an agent crosses a trust boundary. Its authority should not travel with it like a master key. Each handoff should preserve the limits of the original authority or reduce them further, rather than allowing additional rights to appear along the way.
APIs play an important role here because they are often the point where an agent's intention becomes an action in a real system. The agent may reason about what should happen, but the API is where something actually changes. In that sense, the API becomes part of the execution contract.
Observe the Chain
Securing access helps, but it is difficult to control a chain if you cannot see what it is doing.
Most organisations can tell you which applications are registered and may also know which credentials have been issued. What is often much harder to answer is what a particular agent can actually reach right now.
Can it read a file that changes its behaviour? Can it call another API and use the result to continue somewhere else? Can it act through a different identity, and what would the consequence be if it did?
That capability view matters more than simply knowing the name of the tool.
Observation therefore has to follow the action as it moves through the chain. At important points, we need trace points that show which agent acted, on whose behalf
it acted, what context influenced the decision and which authority allowed the action to continue.
That is related to logging, but it is not quite the same thing. Logs are invaluable when reconstructing an event afterwards. Trace points also need to help while the process is still running, because you cannot intervene in an action that has already finished.
Developers are used to this idea. When something goes wrong in software, we want to understand how execution got there and what happened along the way. Agentic systems need the same kind of visibility while they are operating.
Break the Chain
Seeing a problem is useful, but it is not the same as being able to stop it.
A warning on a dashboard does not help much if the payment has already been sent or the change has already reached the production system. At some point there has to be a place where the next action can genuinely be held back.
That is what I mean by a break point.
If important context is missing or the authority no longer matches the task, the chain should not simply continue because all the individual credentials are technically valid. The same is true when the consequence of the next step becomes much greater than the action that came before it.
Depending on the situation, the response might be to reduce the authority or refuse the next call. In other cases, the system may need stronger authentication or somebody who can look at the situation and make the decision deliberately.
That does not mean putting a human in front of every tool call. If people have to approve every meaningful action, the result is not really automation, just a different kind of queue.
Human involvement makes sense where the consequence is difficult to undo or where the context is too uncertain for the system to make the decision alone. Good automation should be able to recognise that point and hand the decision back.
What happens after the break?
Stopping a chain can create problems of its own. In a critical process, simply shutting everything down may cause almost as much damage as allowing the questionable action to continue.
A useful break point should therefore limit what is affected rather than stopping everything around it. An agent might still be allowed to read information while changes
are blocked. A manual process might take over for a while, or the agent may continue with reduced authority until the situation has been understood.
This is where agent security meets resilience and business continuity.
Resilience is not about keeping every process running at all costs. It is about retaining enough control to understand what is happening and decide how the organisation should continue operating.
Those decisions are difficult to invent in the middle of an incident. It helps to know beforehand who can restrict an agent's authority, what happens to important processes while that restriction is in place, and how the organisation returns to normal oncethe problem has been resolved.
Secure. Observe. Break.
AI agents can already perform real tasks, and the question is no longer whether we should allow them to act at all. The more useful question is how we keep their actions within boundaries that we can understand and control.
Securing the chain means making sure that context and authority remain appropriate as the agent moves from one step to the next.
Observing the chain means being able to follow that movement while it is happening and understand what gives the agent the ability to continue.
Breaking the chain means retaining the ability to stop or restrict the next action before an unwanted consequence becomes irreversible.
We will probably never have perfect control over everything that happens inside an AI model. We can, however, decide what an agent is allowed to reach and how much authority it carries with it. More importantly, we can design the surrounding systems so that there is still a point at which we can intervene when the context changes.
The goal is not to stop agentic AI. It is to let agents do useful work without handing over control.
Break the uncontrolled chain, not the agent.