Autonomy Isn't Authority

An agent that runs by itself every morning and an agent that can move money are two entirely different security problems. But some AI risk conversations flatten them into the same thing.

Two distinct agents

The first runs every morning without anyone asking. It searches a set of approved public sources and drafts a briefing. Nobody initiates each run. Nobody reviews it before it runs. If it gets something wrong, the likely damage is a bad paragraph.

The second does nothing until I ask. When I do ask, it executes a five-million-dollar transaction.

Rank them by autonomy and the first one wins easily. Rank them by consequence and it isn't close in the other direction. Both get called AI agents, but only one of them keeps me up at night.

That's the problem with drawing the line around a product label: copilot versus agent, assistant versus automation. These labels will keep changing. What I actually want to know about any AI deployment is much simpler: how independently does it operate, and what is it allowed to do?

Two distinct dimensions

Autonomy is when and how independently something operates. Authority is what it's allowed to do.

Keeping those separate matters because more autonomy does not automatically mean more risk. The morning briefing agent is highly autonomous and nearly powerless. The transaction agent has a human initiating every run and enormous authority. A single "agentic" risk rating doesn't describe either one very well.

What I care about is closer to a set of interacting factors:

autonomy × authority × data sensitivity × exposure

I don't mean that as a literal scoring formula. I mean those are the questions I want answered before somebody tells me a system is enterprise secure.

Which systems can it reach?
How independently does it run?
What data can it see? How far can its actions travel?
What happens if it's wrong, or if someone manipulates it?

Those questions survive the next round of product renaming. The too simple question "Is it an agent?" doesn't.

Human initiation is a control that may be too easy to give away

Consider a request I'd have relatively few concerns about:

Review this document and tell me if anything looks unusual.

A person chose the document, started the interaction, and receives the answer. There are still AI risks in that workflow — hallucination, data exposure, prompt injection — but a human is at the initiation point.

Now change one thing:

Monitor this inbox. When a document arrives, analyze it and take the appropriate action.

That sounds like a productivity improvement. It is also a change to the security model. You've removed the human from the initiation point, which means an external event can now cause the AI workflow to execute.

And whoever can influence that event may be able to influence what the agent sees and, depending on the design, what it does next.

Triggers are worth enumerating explicitly because teams tend to treat them as plumbing: an incoming email, a new document, a support ticket, a database change, a security alert, a scheduled time, an API event, a user action, the output of another agent.

For each one, I want to know:

who can cause this to fire, and who controls the content that enters with it?

If customers can open the ticket that starts the workflow, customer-controlled content is entering an agent. If an agent automatically processes incoming email, internet-originated content is entering an automated reasoning loop. That's a very different security model from "an employee asked Copilot to summarize an email."

The principle I'd apply is straightforward: treat externally influenceable triggers and the content they carry as untrusted input.

This is not a new security idea. Its application security pointed at a new kind of consumer.

The authorization worked exactly as designed. It is the problem.

Here's a distinction that explains why traditional access control is necessary but not sufficient.

If someone steals a password and reaches something they shouldn't, authentication or authorization controls have failed somewhere. We know how to reason about that problem.

But an agent can also misuse access it legitimately has. If an agent is authorized to read email and SharePoint, and malicious content convinces it to find sensitive information and send it somewhere it shouldn't, the underlying permission checks may all succeed. The problem is not necessarily that IAM granted access incorrectly. The problem is that the agent used legitimate access for an unintended purpose.

That's why retrieved content deserves the same suspicion we give other untrusted input.

"It's in our SharePoint, so it's trusted" is not a safe assumption once an LLM is reading it. A document, ticket, repo, knowledge-base article, web page, or tool response can all contain text that the model interprets as instructions.

We spent decades teaching developers not to execute user input. The agentic version is similar: don't let retrieved content become authority. A document can provide data to the task. It should not be able to redefine the task or expand what the agent is allowed to do.

We need to be evaluating combinations, not only connectors

Connector reviews often happen one at a time, and each connector can look reasonable on its own.

An agent that can read email? Okay.
An agent that can access benefits information? Okay, given its job.
An agent that can send email externally? Maybe okay.

Put all three together and you've created a possible path from untrusted input to sensitive data to external action. A connector-by-connector review can miss that because the risk isn't necessarily in any one permission. It's in the sequence.

I've written before that, in an AI inventory, the risk lives in the connections rather than just the assets. This is the same observation moved upstream into the approval process. If the inventory is a graph, the review has to consider the graph too.

The practical answer is architectural. Separate analysis from execution. Keep privileged action paths tightly scoped, and put enforceable controls between a model's recommendation and a consequential action — policy checks, approvals where the consequence warrants them, scoped credentials, constrained APIs.

The point is not that every read tool and write tool must live in completely separate systems. The point is that the combination has to be assessed and bounded.

We need deterministic controls around a probabilistic system

When a team wants to constrain an agent, the first instinct is often to put the rule in the system prompt:

Never send confidential information externally.

That's a useful instruction. It is not an authorization control. If the only thing preventing the action is the model deciding to follow that sentence, the model is also part of the enforcement mechanism.

LLMs are probabilistic, but our authorization controls don't have to be.

Put hard constraints in the orchestration, identity, policy, or tool layer, where they can be enforced regardless of what the model concludes:

This agent cannot send external email.
This identity cannot access that repository.
Transactions above this threshold require approval.
This tool cannot be invoked from an externally triggered workflow.

Credentials work the same way. Tokens, API keys, and service credentials should not live in prompts, agent memory, source code, or other model-visible context. Ideally the model never sees the credential at all. A trusted execution layer holds it and uses it only for an authorized tool call.

Prompts are useful behavioral controls, but they are not appropriate to act as your primary authorization controls.

The same logic applies to blast radius. Two questions to consider:

If this agent gets it wrong, can we easily undo it? Creating a draft ticket and permanently deleting data are not the same action. Drafting an email and sending a legally consequential message to a customer are not the same action. Recommending that an account be disabled and actually disabling the CEO's account are not the same action.
What's the worst this agent could do if it behaved incorrectly for an hour? If the answer is five bad draft tickets, that's one design conversation. If the answer is every customer in the database receiving an email, that's another.

Then contain the blast radius architecturally rather than relying on good model behavior: rate limits, transaction limits, scoped APIs, restricted toolsets, bounded execution windows, circuit breakers and kill switches. Design for the possibility that the model gets it wrong.

I'm not arguing that agents are inherently dangerous, and I'm definitely not arguing for a human to approve everything. Put a human approval in front of every action and you've mostly built expensive autocomplete.

I'm arguing that "is this an agent?" is not a useful enough security question. More useful questions include: