Declared Authority Is Not Enforced Authority
An authority inventory is only as honest as the engineer who filled it in, which is why the record that survives an audit is the one a runtime writes while enforcing its own boundaries.

An authority inventory for an AI agent is exactly as honest as the engineer who filled it in. That is tolerable when the inventory lists packages and versions, because a build produces those facts whether anyone is paying attention or not, and it stops being tolerable when the inventory describes what an agent is permitted to do, because permission is assembled at deployment out of prompt templates, tool registries, credential scopes, memory configuration, and whatever human-in-the-loop control quietly stopped being enforced. The one thing nobody types into a form is what the system actually refused to do last Tuesday.
For the platform engineer who has to defend an agent in an audit a year from now, that distinction decides the whole conversation. A record assembled ahead of a review answers what someone believed was true on the day of the review. A record the runtime emits out of enforcement decisions it already made answers what happened, and it changes what drift means, because an autonomy increase or a removed approval gate becomes a gate that fires before the change reaches production.
The Field Vocabulary Is Close to Right
The security question around a tool-using agent has changed shape, and the review vocabulary is converging on close to the right set of questions. One recent evaluation built a typed authority schema and filled it in against thirteen real, documented open-source agents across three archetypes: coding agents, retrieval-augmented generation agents, and multi-agent systems. A record of that kind carries agent identity, model and prompt metadata, tool descriptors and tool-risk tiers, autonomy level, memory and data sources, approval gates, audit signals, inter-agent communication, credential scope, control mappings, and references out to the software and model bills of materials that stay authoritative for dependencies and training provenance. That is the correct unit of review. A dependency inventory can tell you that an agent imports a browser library; whether that agent may send mail to an external domain without a human approving it is a question the package list has never been able to answer.
Strip the schema down and three questions carry it.
- What may it do: the tools, the risk tiers, and the autonomy an agent is permitted to reach.
- With whose credentials: the scope of the secrets, memory, and data surfaces it can touch.
- Under whose approval: the gates standing between an intention and an action.
Those three questions are the spine of the review.
We hold the same view about the unit, which is why the vocabulary matters more than the file format. Autonomy level, maximum tool tier, credential scope, memory persistence, approval gates, and audit signals are the properties that decide whether an incident can be reconstructed or only regretted. Giving them consistent names is real progress for the reviewers, platform engineers, and governance teams who have been asked to sign off on systems whose authority was scattered across six configuration surfaces and one person's memory.
Declaration Is the Weak Joint
Sourcing is where this gets difficult. A schema is a container, and a container inherits the reliability of whatever fills it. Any declared authority artifact depends on accurate declarations about tools, credentials, memory, approval gates, and logging, and an incomplete artifact obscures risk the way any transparency mechanism can. A hand-maintained record drifts in the interval between the moments someone remembers to update it, and the fields most likely to be stale are the ones that matter most during an incident: the credential widened for a migration and never narrowed again, the approval gate disabled to unblock a release on a Friday that nobody re-enabled on Monday.
The record worth having is the one a system produces while enforcing its own boundaries.
The remedy is a question of placement.
This is why we put the compliance surface in the runtime, where the enforcement already happens. Data classification is a hard, first-priority gate in the model router, it fails closed, and it is re-applied on every failover hop, so a request carrying restricted data cannot be quietly downgraded to a provider that should not see it during an outage. A tool cannot execute unless its running code matches its registered checksum, its module sits on a build-derived allowlist, and its classification ceiling clears the agent, and every refusal writes an audit entry. The audit record is designed to be safe by construction, carrying identifiers, classifications, codes, and hashes with no free-text payload field to leak, append-only and partitioned with deletion and truncation revoked. Instrumentation sits at the framework level, so any agent that runs is wrapped by construction and the developer has no opt-out.
None of that is a running product. The foundation is built and tested, the first flows are specified and not yet wired, and we will describe outcomes when there are receipts to describe. What we can state precisely today is where the enforcement lives, and that placement is the whole argument, because the fields a reviewer wants to see are the same fields the runtime has to consult before it can decide anything at all.
Drift Belongs in the Merge Gate
Authority drift is the right name for the failure mode. The base model, the application code, and the package set can all look unchanged while a new write-capable tool, a broader credential scope, persistent memory over sensitive data, or a reduced approval requirement changes what the agent can actually do. Thirty-three structured deployment mutations injected into declared authority records were all identified by a diff detector and assigned the correct change type, which is complete recall for structured authority drift as represented in typed fields. Read that scope precisely: it covers changes declared in the schema, and general vulnerability discovery sits well outside the boundary.
The interesting move is what happens to that same comparison when the fields are sourced from enforcement. A record the runtime produces as a byproduct of decisions it already made has no interval in which to drift, because there is no distance between the declaration and the behavior being declared. Under that arrangement the diff leaves the review meeting and moves into continuous integration, where a widened credential scope or a newly registered destructive tool blocks a merge the way a dropped evaluation score does.
The two changes that hide inside a release
Two entries in that vocabulary deserve heavier treatment than the rest. An increase in autonomy level and the removal of an approval gate carry the largest blast radius and the smallest diff, and both ship easily inside a routine release. Treating them as ordinary configuration is how a system that was defensible in March becomes indefensible in June without anyone making a decision they would have recognized at the time as a decision.
Our position on autonomy predates this vocabulary. Declarative, versioned workflows validated before they run, each step carrying an explicit failure policy and the whole run carrying an enforced time budget, are what we build on, because they can be tested and audited. The route to dynamic supervision is designed and gated: a candidate supervisor first runs in shadow, recording the call it would have made, and that shadow record is the evidence that earns the permission. We describe supervised autonomy as a designed, shadow-gated path because that is what it is today, and the care in that sentence comes from the same place as the care about where an authority record originates.
What a Score Can and Cannot Do
Scoring is where an artifact like this usually overreaches, and the restraint that keeps it useful is worth naming. A secondary penalty-based scorer using different weights produced a Spearman rank correlation of 0.73 with the primary rule-based score, which supports the ordering the primary score produces. Categorical label agreement across five labels came in at 46 percent, and that is the figure that keeps the whole scoring layer honest, because coarse bands need calibration against human security reviewers before they carry weight.
We read that as the correct boundary and a useful one. A score that ranks a set of agents by review priority and exposes the drivers behind the ranking sends scarce reviewer attention to the right place first. A score that issues a verdict quietly substitutes itself for the judgment a governance team is paid to exercise, which is the one thing an artifact of this kind should never be asked to do.
The argument ends where the audit begins.
The record worth having is the one a system produces while enforcing its own boundaries. A year from now, when counsel asks where restricted data was processed, or an auditor asks which agent was permitted to move money and under whose approval, the answer either sits in an append-only log written at the moment of the decision or it gets reconstructed from memory and good intentions. Architecture decides which of those two conversations a team gets to have, and that decision is made long before the question arrives.
More from Insights

Your Evaluation Judge Is a Component
An evaluator that has never been calibrated or attacked reports its own blind spots, and every governance figure downstream inherits them. Treat the judge as a registered component.

The Judge That Gates Your Agents
A judge with unmeasured preferences turns a regression gate into selection pressure, and swapping positions plus majority voting cost far less than three retrains of drift.

Which Memory Layer Are You Buying
Two systems both called memory can owe entirely different obligations: one holds state for a single run, the other has to be viewable, removable, tenant-isolated, and auditable years later.
Orchestration that earns autonomy.
Let the Runtime Write the Record
Remember what worked. Apply it faster. Prove what you did.