Authorized to Operate Is Not Allowed to Act

A federal customer asks what your agent is allowed to do, on whose behalf, against which resources, and what stops it when those conditions are not true. An ATO establishes that a system meets an approved security baseline. It does not answer any of that. The deadline for documenting high-impact AI uses has already passed, and the control catalog has not caught up.

An agency Chief AI Officer asks a software vendor for evidence of the controls governing what its production agent is allowed to do.

The vendor has an ATO, a SOC 2 Type II report, a current penetration test, architecture diagrams, and model documentation.

None of them answers the question.

The request lands with Wes, who runs engineering at a software company that has sold into the federal government for years. His team recently added an agentic feature to a platform an agency uses for real work.

The agency is documenting its high-impact AI uses under OMB M-25-21. Wes's agent sits inside one of those workflows, and they need evidence of the controls governing what it is permitted to do.

By lunch, Wes realizes he can send every assurance artifact he has and still answer nothing.

The ATO answers a different question

Wes is very good at proving that a system is authorized to operate.

That is not what the agency asked.

They want to know: What is this agent allowed to do? On whose behalf? Against which resources? Under what conditions? What stops it when those conditions are not true? And can you prove those controls are working?

His existing evidence describes the platform's security posture. It does not show what this agent is allowed to do, whether anyone tested those limits, or whether anything enforces them when it runs.

An ATO can establish that a system meets an approved security baseline.

It does not establish that a procurement agent may approve purchases only below a defined dollar threshold, for authorized users, through approved tools, under specific conditions.

Those are different claims.

He goes looking for the control and finds a gap

Federal security reviews have a familiar grammar: map evidence to controls, describe the implementation, attach the evidence.

So Wes looks for the control that says:

This agent may take these actions, against these resources, under these conditions, and the system will prevent anything else.

The existing catalog covers pieces of the problem, but not one tested answer to what this agent is allowed to do.

NIST is working on that problem. Its Control Overlays for Securing AI Systems project includes overlays for single-agent and multi-agent systems. Those overlays are still in development.

Federal customers, meanwhile, are already asking for the evidence.

The catalog hasn't caught up. The requirement has.

The deadline already passed

OMB M-25-21 was issued on April 3, 2025. For high-impact AI uses, agencies had 365 days to document implementation of the memo's minimum practices.

That deadline was April 3, 2026.

A noncompliant high-impact use may have to be safely discontinued. There are limited exemptions and a waiver process, but the consequence is real.

The Chief AI Officer is not inventing a procurement hurdle. The agency has a live use case and a documentation obligation.

For the vendor, that is not a paperwork problem.

It is a product problem.

A human in the loop does not automatically solve it. If AI output is a principal basis for a consequential decision, the use can still qualify as high-impact.

The agency cannot answer this without the vendor

The agency owns the use case and obligation. It can evaluate the system, establish oversight, and document how it is used.

But it did not build the agent. The vendor holds the tool schemas, requested scopes, configuration, prompts, and enforcement path.

M-25-22 points in the same direction. Agencies are expected to evaluate AI performance and risk throughout acquisition and use, which means vendors can be asked for documentation, testing access, and independently verifiable results where practicable.

“We tested it internally and it performs well” is not enough.

Wes is being asked for evidence only the vendor can produce.

The inputs already exist. The answer does not.

Once Wes stops hunting for a control number, the problem gets easier to see.

His team already knows most of what the agent is and isn't allowed to do. Pieces of that answer are scattered across tool schemas, requested scopes, code review comments, the system prompt, and the paragraph in the runbook that starts with “never.”

The problem is that those rules are incomplete, inconsistent, and sometimes stale. Nobody has reconciled them into one current statement, tested that statement against the real agent, and systematically enforced it.

The rules hold because the team is disciplined, not because the system is.

The distance between:

Our engineers know the agent should never do that.

and:

The system will not permit the agent to do that.

is the distance between an intention and a control.

It is also the distance between the evidence Wes has and the evidence his customer asked for.

Four things an engineering team can do now

You do not have to wait for the final NIST overlay.

1. Write down what the agent is allowed to do

Start with the artifacts that shape its production behavior: prompts, tools, permissions, workflows, integrations, configuration, and intended purpose.

Then express the rule in terms of actions, resources, and conditions.

Not payments, but: the agent may initiate payments below this threshold, for this class of transaction, on behalf of this authenticated user, through these approved tools, under these conditions.

Turning those inputs into one coherent rule is the work.

2. Try to break it before you ship it

Test the actual agent against that rule.

Try to make it act outside the rule. Keep the findings. Use them to tighten the rule before anything enforces it.

A test that finds nothing should make you question the test before it makes you trust the agent. That becomes evidence of pre-deployment testing and risk mitigation.

3. Make the decision when the agent acts

Turn the corrected rule into policy and apply an allow-or-deny decision before the action executes.

The facts that determine whether an action is acceptable often do not exist until execution time: the amount, destination, user, record, and tool. That is where the decision belongs.

A sentence in a system security plan is evidence of intent. A decision made against a named constraint before execution is a control.

4. Record the decision and why it was made

For each material action, record what the agent attempted, whether it was allowed, denied, or escalated, and which constraint produced the decision.

Connect that record back to the policy and test findings behind it. Now a customer or assessor can sample the control directly instead of reconstructing it from an activity log.

When the agent changes, go back to step one. A new tool, wider permission, revised prompt, or model upgrade can all change what the agent is effectively able to do.

This has to be a lifecycle, not a launch checklist.

Build the capability, not the paperwork

The evidence package itself is not reusable. Each deployment has its own configuration, connected systems, permissions, and often customer-authored workflows.

What you build once is the pipeline that produces it.

The rules. The testing. The enforcement. The decision records.

That is the durable asset, and it is an engineering asset, not a compliance artifact.

Build the pipeline once. Let it produce evidence for each deployment. Ship that capability with the agent.

A vendor that can show an enforced rule, adversarial test results, and decision-level evidence is in a different position from a vendor attaching another SOC 2 report.

One answers the question being asked. The other does not.

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.

TenetGraph determines one current answer 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 proposed rules. Adversarial reinforcement learning keeps looking for ways the agent can reach outside the intended constraints. Each finding tightens the rules before enforcement.

Once approved, the policy is enforced deterministically before execution, through TenetGraph or an existing 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.

One engineering loop instead of separate documentation exercises for testing, monitoring, and oversight.

The bottom line

An ATO, SOC 2 report, and penetration test are real evidence about the system.

Your customer's Chief AI Officer is asking a narrower question about the agent:

What is it allowed to do? What did you test? What is actually enforced? And what happened when it acted?

Those are different questions.

There may not be a final control ID yet. That is not a reason to wait.

Vendors will have to solve this first because they hold the artifacts, build the agents, and control the enforcement path.

Somewhere in your repository is a paragraph describing what your agent must never do.

Right now, it is documentation.

The job is to make it a control.