The outcome you are walking toward
A defensible answer to the question every reviewer eventually asks: what is this agent allowed to do, who decided that, and where is the proof? You finish able to check each layer of the authority model against a written specification, not against a demonstration.
1. Start from the manifest, not the prompt
An agent on this platform is specified as not a prompt — it is a versioned, signed software package whose capabilities are declared in a signed manifest. The design principle is stated plainly: authority is data, not code. What an agent may do is carried in structured, typed capability declarations (for example, a read on a specific data class, or a command proposal of a specific type), not buried in implementation or implied by instructions. The enforcement rule is equally plain: no capability, no action. When you review a deployment, ask for the manifest of one agent and confirm the capability list is data you can diff, sign, and revoke — not prose.
2. Read authority as an intersection, not a switch
Authority is the intersection of five inputs: the manifest capabilities, the applicable policy packs, a short-lived runtime grant, human approval gates for high-impact actions, and the agent's current mode. This is what an authority envelope means in practice — an agent acting in production holds Act (Scoped) authority: it can execute only within narrow envelopes, and on the edge it is designed to run only within pre-approved authority envelopes. Elevated authority exists but is temporary and held under dual control; disabled agents retain an installed package but execute nothing. No single layer is sufficient on its own, which is the point.
3. Check the gates and the observation mode
Two mechanisms keep a person in the loop by construction. First, high-impact actions require approval gates — spend-class capabilities are described as almost always gated, and gate releases are recorded events, covered in approval gates for autonomous agents. Second, every agent supports an observation-only mode: it produces proposals and traces but cannot emit acting commands, and agents can be placed in observation-only mode instantly. This is the designed path for introducing a new agent or a new version — it earns scope from observed behavior rather than being granted scope on arrival.
4. Reconstruct one action from the evidence tuple
For every decision that can affect the real world, the system is designed to write a full evidence tuple: observations hash, policy revision, agent version and package digest, decision trace, command issued, and result. On the edge, the contract is stricter still — all agent actions emit reconstructable evidence locally before any side-effect. The record is what makes "why did the agent do that?" answerable months later. The verification step is the one in Verify the audit trail hands-on: pick one consequential action and rebuild it from the record, against the evidence model, not from a narrative assembled for you.
5. Push on the two failure edges
Two questions separate a governed system from a hopeful one. Can an agent expand its own authority? The specification lists hard constraints an agent can never override: it cannot expand its own capabilities, cannot disable evidence collection, cannot override a human denial, cannot spend above approved ceilings, and cannot access data outside its declared privacy class. What happens in a genuine emergency? Emergency local override exists only through pre-authorized, audited break-glass procedures — dual control on elevated authority, and every step in the evidence record. An emergency path with a full audit trail is a control; one without it is a liability. Both answers are verifiable in a live review session — request them through the diligence resources path rather than taking this page on faith.