There's No Scope For That

Least privilege assumes you can issue a privilege roughly the size of the job. With agents, you often can't. A security engineer grants the narrowest scope her identity provider offers, and it is still wider than the rule she actually meant. The difference between the permission granted and the job intended is the agent's real authority, and that is where the incident lives.

Least privilege assumes permissions come in roughly the size of the job.

For agents, they usually don't.

Call her Priya. She's a composite of the platform and product security engineers I've talked with this year, but the Slack thread is real at almost every company shipping agents.

The ask is simple. A support agent goes to staging Thursday. It needs to look up accounts, read order history, issue refunds, and update shipping addresses.

Can you get it access?

Priya does what a good security engineer should do. She gives the agent its own identity instead of reusing a service account or letting it ride on a human token. She chooses the narrowest roles available. She binds a specific set of tools instead of pointing it at the whole catalog. She puts approvals in front of destructive actions. She logs what it does.

That isn't a shortcut. It's better than what most teams are doing today.

Then she hits the problem everyone eventually hits.

There is no scope for what the agent actually needs to do.

The permission isn't the rule

The refund rule is not refunds.

It's closer to this:

The agent may refund up to $200 against an existing order for the customer authenticated in this session, back to the original payment method, and never to another payout destination.

Priya's identity provider has refunds.

So that's what she grants.

Everything that makes that permission safe has to live somewhere else. Usually the system prompt. Maybe the tool description. Maybe a security ticket or a comment above the handler.

That's the gap.

Every agent permission gets rounded up to the nearest thing the permission system knows how to express. The difference between the permission you granted and the job you intended is the agent's real authority.

That's where the incident lives.

This isn't bad IAM hygiene. Scopes are built around APIs. Roles are built around job functions. Neither was designed to describe one agent doing one task under one specific set of conditions.

Least privilege assumes you can issue a privilege roughly the size of the job.

With agents, you often can't.

What happens when you round up

The consequences are predictable.

First, the privilege sticks.

Priya grants the broader scope because the team ships Thursday, with a note to tighten it later. Nobody tightens it later. Anyone who has operated production systems knows how this goes. Permissions rarely get narrower on their own.

Then permissions combine.

Read the knowledge base. Read the customer record. Send a message.

Each permission is defensible by itself. Together, they may create an exfiltration path nobody explicitly reviewed.

Authority also travels.

The agent calls a tool. The tool calls another service. The easiest implementation is often to pass along the authority the agent already holds.

We saw a version of this in the 2025 Drift compromise. Attackers obtained OAuth tokens and used the permissions attached to them against hundreds of Salesforce environments. They didn't bypass the authorization system. The tokens did what they were authorized to do.

That was the problem.

And eventually somebody asks the uncomfortable question:

What was this agent allowed to do?

You can show them the roles. You can show them the scopes. You can show them every API call it made.

None of those is the rule.

The real rule was the one Priya wrote in prose, and nothing ever made a decision against it.

You have a record of activity.

You don't have a record of judgment.

Tightening further eventually stops working

The obvious answer is to narrow further.

Split the roles. Gate more calls. Require a human approval before anything writes.

That works until humans are confirming actions at machine speed.

Then the control starts losing.

Anyone who runs coding agents has seen the industry's most honest artifact here: a command-line flag called --dangerously-skip-permissions.

It's basically a warning label with syntax.

And careful people still use it because approving every file write by hand destroys the value of the agent.

A control at the wrong granularity doesn't keep getting tightened.

Eventually, people turn it off.

The prompt is not an enforcement point

The other workaround is to put the real rule in the system prompt.

That's already where a lot of teams put it.

But a prompt is an instruction to the model. It can be carefully written and reviewed by product, security, engineering, and legal. It can be explicit. It can say "never" in bold letters.

It's still an instruction sitting in the same context as user input, retrieved documents, web pages, and tool responses.

A control shouldn't depend on the model agreeing with you.

The Replit incident last year made that painfully concrete. An AI coding agent deleted a production database during a code freeze after being told repeatedly not to make changes.

The agent had production write access because that was the permission granularity available.

The instruction not to use that authority lived in the conversation.

A conversation isn't an enforcement point.

So Priya winds up choosing between a control her team will eventually disable and a rule that was never actually a control.

You've probably already written the rule

Here's the useful part.

Priya already knows what the agent is allowed to do.

So does her team.

It's in the system prompt. It's in the security ticket. It's in the tool description. It's in the runbook. Some of it is implicit in the code.

The knowledge isn't missing.

It's scattered across artifacts that can influence the agent but don't constrain it.

And those artifacts don't necessarily agree. Some are stale. Some describe the design instead of the agent that is actually running.

That changes the problem.

You don't need a new security taxonomy for agents.

You need to turn the rules your team is already writing into controls.

Four things you can do now

1. Write the job as a rule, not a role

The unit isn't refunds.

It's the action plus the conditions that make the action acceptable.

What amount? Which customer? Which order? Which destination? Under what session? Through which tool?

Start with what's already in your prompts, tool schemas, configuration, and security documentation.

Expect those inputs to disagree.

Reconciling them into one current statement is the work.

If you can explain the rule to a new engineer, you can write it down.

2. Try to break it before you ship it

Test the agent that's actually going to production.

Not the one in the architecture diagram.

The real agent has a particular model, prompt, tool set, permissions, configuration, and integration surface. Change any of those and you've changed the system.

Try to make it act outside the rule.

Keep what you find and use the findings to tighten the rule before enforcement.

A rule you haven't tried to break is still a hypothesis.

And a test that finds nothing may say more about the test than the agent.

3. Decide when the agent acts

A scope is granted before the request exists.

At that moment, the identity system doesn't know the refund amount, the customer, the order, the payment destination, or what else is happening in the session.

Those facts exist when the agent attempts the action.

That's where the decision belongs.

At the tool call. Before execution.

IAM should still determine what the agent can reach.

But the action-level decision has to determine whether this particular use of that authority is allowed.

4. Record every decision and what produced it

Don't just log that the agent called an API.

For each material action, record what it tried to do, whether the action was allowed, denied, or escalated, and which constraint produced that decision.

Now the question:

"What was this agent allowed to do, and did the control hold?"

becomes a query instead of an argument.

When the agent changes, go back to step one

A tool gets added. A permission widens. Someone changes the prompt. The model gets upgraded.

Any of those can change what the agent is effectively able to do.

A developer adding one tool during a sprint may change the agent's authority materially even if your release process doesn't classify it that way.

Change sends you back to step one.

It isn't a fifth step. It's the loop.

Your customer makes this harder

Software vendors have another problem.

You ship the agent, but the customer defines part of the job.

They connect their systems. They choose tools. They configure workflows. They may widen permissions or add data sources you never saw during product development.

You provisioned the product.

They created the operating environment.

Now their security team wants to know what the agent can do in their deployment and what prevents it from going outside that.

That turns this into a procurement problem as much as an engineering one.

The same discipline applies, but the rule can't always be written once at design time.

The rules may need to be set for each deployment.

Which means the durable thing isn't one policy.

It's the pipeline that produces the policy.

Where TenetGraph fits

The pieces that describe what an agent is supposed to do usually already exist across its code, system prompt, tool schemas, permissions, and configuration.

They just don't add up to one current, tested rule set on their own.

TenetGraph determines that rule set from those artifacts, and the person who owns the agent reviews and approves it in plain English.

Then we test it.

Static analysis and red-team simulations probe the rules first. Adversarial reinforcement learning keeps looking for ways the agent can operate outside the intended constraints. Each finding tightens the rule set before enforcement.

Once approved, the rule set is enforced deterministically at the tool call, before execution, through TenetGraph or a supported external enforcement point.

Every allow, deny, and escalation is recorded against the constraint that produced it.

When the agent changes, the process runs again.

Determine it. Test it. Enforce it. Prove it.

The goal isn't to make security teams hand-author another policy language.

They've already written the rules.

We're making them enforceable.

The bottom line

Your IAM system can tell you what an agent can reach.

It was never designed to tell you what this agent, doing this job, under these conditions, is allowed to do.

That's a resolution limit in the permission system, not a failure of security rigor.

Today, most teams make up the difference with prose.

You've already written the inputs.

Turn them into a rule that binds. Test it. Enforce it. Keep the evidence.

Detection determines how often the rules get tested.

What the agent is actually allowed to do determines what a miss costs.