AI Agents Don't Have Managers

Every security control we have ever built assumes that a person at the end of the chain is ultimately responsible for an action.

Awareness training relies on people recognizing risk and changing their behavior. Access controls are built around identities and the permissions attached to them. Disciplinary policy provides a means of holding people accountable. Even our incident language carries the assumption: we talk about compromised users, insider risk and human error. The whole discipline is organized around the idea that behind every action there is eventually a name, and that name belongs to someone who can be called at two in the morning.

AI agents break that assumption quietly, which is why many organizations have not noticed the shift yet. An agent operating under delegated authority represents a new category of principal. It holds credentials, makes decisions and chains actions across systems, all at a speed and scale beyond typical human workflows. What it does not have is a line manager, onboarding, a probation period or any of the organizational structures that have reinforced enterprise security and accountability for the past 30 years.

That is the actual shift. Not machine speed. Accountability.

The identity we forgot to underwrite

Ask a security team how many service accounts exist in their estate and you will get a grimace. Ask how many AI agents are running and you will often get a shrug, because the honest answer is that nobody in security created them.

Agents are being built by people in finance, operations and marketing, using low-code tooling that was designed to remove friction. That was the point. The friction it removed included the review step where someone asked what permissions this thing actually needs.

So the agent inherits the maker's access and permissions. It runs with the maker's standing credentials because that was the path of least resistance at build time. It gets write access to a connected system because someone anticipated a future permissions request they did not want to raise twice. It gets attached to an MCP server as a knowledge source, and MCP servers expose broad action sets by design.

None of those decisions were malicious. Most were not even careless in context. They are the completely rational output of a system that gave business users the ability to create privileged automation and gave security no corresponding ability to see it.

This is the part worth sitting with. The agentic risk accumulating in most enterprises right now is not sitting in exotic model behavior. It is sitting in permissions. Boring, mundane, over-scoped permissions, granted by people who did not know they were granting them, attached to identities that no one owns.

Why prompt injection is a distraction from the real problem

The research conversation has fixated on jailbreaks and prompt injection, and for good reason. Those are valid techniques, and they work.

But focusing there mistakes the trigger for the payload. Consider what a realistic agent incident looks like. Repeated jailbreak attempts against a Copilot Studio agent, followed by that agent attempting to invoke an email-sending tool several times inside a short window. Runtime protection blocks the invocation. The alert carries timestamps, source IP and the identity the agent was acting on behalf of. An analyst correlates it, concludes the credentials are probably stolen, revokes the session and forces a reset.

Textbook. The control worked. Everyone goes home.

Except the interesting question was never whether that one tool call was blocked. It was what else that agent could reach. And if that agent is holding an MCP connection with write access under a maker's standing permissions, then the blocked email attempt was a probe against the least interesting door in the building.

The jailbreak is how the attacker gets to talk to the agent. The permissions are what the conversation is worth. Defending the first while ignoring the second is how you end up with an incident report full of successfully blocked alerts and a breach nobody can explain.

Know where in the stack the manipulation occurs

For security operations, the useful question is not whether your AI can be manipulated. Assume it can. The question is where in the stack that manipulation lands, because the answer determines who detects it and whether anyone is looking.

There are several distinct layers, and they fail differently. The input layer, where a user or a piece of retrieved content shapes the instruction. The model layer, where behavior is influenced through the weights or the system prompt. The knowledge layer, where a poisoned document or a compromised data source changes what the agent believes to be true. The tool layer, where intent becomes action. The identity layer, where the agent's permissions decide how far that action travels. And underneath all of it, the infrastructure the whole thing runs on.

Most organizations monitor exactly one of those, usually the input layer, because that is where the vendor demo happens. Meanwhile the knowledge layer is invisible to the SOC, the tool layer is logged somewhere nobody reviews, and the identity layer is a maker credential nobody scoped.

An attacker does not need to defeat the model. They need to find the layer you are not watching and work there. Mapping that honestly, layer by layer, is the single most valuable thing a security operations team can do in the first ninety days of an agent program. It is unglamorous. It also tells you exactly where your detection coverage stops.

Private AI and sovereign workloads change who owns the layers

That mapping exercise becomes considerably more consequential when the AI runs inside your own boundary. Organizations move to private AI and sovereign deployments for good reasons. Data residency obligations. Regulatory scrutiny. Contractual commitments about where inference happens and who can compel access to it. In defense, government, healthcare, financial services and critical national infrastructure, those are not preferences. They are conditions of operating.

But sovereignty is a transfer of responsibility, not a reduction in attack surface. When the model runs in your tenant, your region or your data center, you inherit layers that were previously somebody else's problem. The inference endpoint is yours to protect. The vector store and the retrieval pipeline are yours. The fine-tuning process, the model artefacts, the GPU infrastructure and the network path between them are all now inside your accountability boundary, and inside the scope of your next audit.

There is a harder edge to this. Sovereign and private deployments typically hold the most sensitive data in the organization and frequently run on the least mature tooling, because governance and observability capabilities tend to land in public cloud platforms first and reach isolated environments later. The workloads with the highest consequence often have the thinnest telemetry. That gap is where security operations earns its budget.

None of this argues against sovereign AI. It argues for going in with the layer map already drawn, knowing which controls travel with the workload, which ones you need to build yourself, and which gaps you are willing to accept temporarily. Deliberate risk acceptance is a legitimate position. Discovering the same gap during an incident is not.

Posture is the discipline, detection is the outcome

Understanding where agents can be influenced, what they can access and where security coverage ends changes what a security operations center (SOC) should actually be doing about agents.

Real-time detection and blocking of malicious tool invocation are valuable controls. But detection on its own puts the SOC in a permanent reactive crouch against an object class that multiplies faster than analysts can baseline it. Normal agent behavior is a moving target because the agents themselves are rebuilt weekly by people who do not file change requests.

The leverage is upstream. Which agents exist, who owns them, what they can reach and whether that reach is scoped or inherited. Those are answerable questions, and answering them across a tenant for the first time is usually an uncomfortable exercise. Multiple agents with Model Context Protocol (MCP) tools configured under maker credentials is not an unusual finding. It is close to the default state.

That is what makes the Agent 365 approach interesting, and it is worth being precise about why. It is not that Defender gained agent alerts. It is that the agent becomes a first-class object with a registry entry, an Entra identity, an owner, a permission scope, runtime telemetry and a data-interaction record, all describing the same thing. The SOC and the platform team stop maintaining separate mental models.

Anyone who has run a breach call knows how much time gets burned on that reconciliation. Whose thing is this? Who can turn it off? Does anyone have the console?

Containment needs an owner before it needs a runbook

Because here is where agentic response actually fails, and it is not a technology failure. An analyst can revoke a user's session. An analyst usually cannot unpublish an agent. Blocking a risky agent from the store, cutting off existing users and holding it until a scoped version ships are administrative actions in a different console, owned by a different team, with a different change process and probably a different reporting line.

So, the finding becomes a ticket. The ticket lands with people who do not have the incident context. The agent stays live for another fortnight.

The organizations that will handle this well may not be those with the best detection content, but those that decided, in advance and in writing, who has the authority to block an agent and how quickly they can act. That is a governance answer to a security problem, which is unfashionable, but it is the answer, regardless.

What security teams can do today

More than most people assume, and less than the market is selling. Both are worth saying plainly.

Agentic threat modelling is still maturing, and detection content will need calibrating as it beds in. That is the normal shape of a new control surface. Every capability the SOC now relies on went through the same phase, and the teams that came out ahead started early enough to build the baselines themselves rather than inherit someone else's.

What is available today is narrower than the hype and considerably more useful. You can know which agents exist in your estate. You can know who made them and what they can touch. You can map the layers they can influence and see clearly where your coverage ends. You can see their activity next to the rest of your telemetry, block malicious invocation in real time and find the over-scoped ones before someone else does.

That is a strong position. Most of the exposure in this space is discoverable, and discoverable risk is the kind security teams have always been good at retiring. The organizations moving now are not doing anything heroic. They are running the inventory, scoping the permissions, and deciding who owns the block decision, in that order, while the estate is still small enough to get ahead of.

That work is straightforward with the right visibility and the right people looking at it.

Talk to our security specialists about mapping your AI agent landscape, across public, private and sovereign environments. We will help you see what is running, understand which layers carry real exposure, and build the operating model to keep pace as your agent estate grows.