# Governed Agent Systems — 002 ## The Authority Envelope If capability is not permission, permission needs a form. “Authorised” is too weak a word when it floats free of scope, purpose and conditions. A person may authorise an agent to investigate an incident without authorising it to repair production. A finance lead may permit spending without permitting any amount, from any account, for any purpose. A user may permit access to email for scheduling without delegating the right to negotiate on their behalf. The useful question is therefore not simply whether an agent has permission. It is: **Permission to do what, for whom, where, under which conditions, for how long, and with what consequences?** A governed agent needs an answer that can survive contact with execution. That answer is the **authority envelope**. ## Permission needs jurisdiction An authority envelope defines the region in which an artificial delegate may exercise judgement legitimately. It does not prescribe every action in advance. It establishes the jurisdiction inside which actions may be selected. That distinction matters. A script follows instructions. An agent may choose methods, sequence work, react to evidence, use different tools and discover useful intermediate actions nobody explicitly specified. If governance requires every such choice to be pre-approved, the system has been reduced to expensive automation. But if an objective such as “fix the incident” is treated as permission to do anything that might contribute to fixing it, the agent has no meaningful boundary at all. The envelope sits between those extremes. It gives the system room to exercise judgement without allowing judgement to manufacture jurisdiction. > **Permission should have an inspectable boundary.** ## The principal comes first Authority has a source. Before an agent can act legitimately, some principal must possess relevant authority and delegate part of it. The principal may be a person, role, institution, policy-defined function or another delegate that is itself permitted to subdelegate. The crucial point is that delegation cannot create authority from nothing. If an employee lacks permission to release customer data, their agent does not gain that permission merely because the employee asked confidently. If a team lead cannot sign a contract, delegation to an agent does not convert enthusiasm into signature authority. A delegate cannot pass onward more jurisdiction than it legitimately possesses. This gives the envelope a provenance requirement: **who granted this authority, and why were they entitled to grant it?** Without that, the envelope is only a configuration object wearing a lanyard. ## What an authority envelope should contain The exact representation can vary, but a useful envelope normally needs enough information to answer several classes of question. ### Identity and principal Who is the delegate? Who is the principal? If the instruction arrived through an interface, account or delegated service, what establishes that those identities are the relevant ones? Identity does not itself create authority, but authority that cannot be attached to identifiable actors is difficult to govern. ### Objective What is the delegate trying to achieve? Objectives matter because the same technical action may be legitimate for one task and illegitimate for another. Reading a customer record during an authorised support case may be valid; reading the same record because it might be interesting is not rescued by identical credentials. The objective constrains relevance. ### Scope Which resources, systems, repositories, accounts, records or domains are included? “Access to GitHub” is not a scope. “Repository X, issues and pull requests, no organisation settings” is closer. “Manage email” is not a scope. “Read messages related to travel bookings and draft replies for review” is. Scope turns broad technical access into task-specific jurisdiction. ### Action classes What kinds of actions may the agent perform? Reading, drafting, sending, deleting, purchasing, deploying, changing permissions and entering contracts are not merely different API calls. They represent different kinds of consequence. An authority envelope should be able to distinguish them even when one credential makes them all technically available. ### Constraints What limits apply? Constraints may include budgets, rate limits, data classes, approved counterparties, time windows, risk thresholds, geographic restrictions, environments, communication channels or requirements to preserve reversibility. These constraints are part of the authority, not optional advice attached afterward. ### Evidence requirements Some actions should occur only when particular evidence exists. An agent might be allowed to issue a refund below a threshold, but only when the payment record confirms settlement and the request comes from the authenticated account holder. It might deploy a release only after tests pass and the approved commit is still the one being deployed. The envelope can therefore define not merely *what* is allowed, but what must be established before the permission becomes exercisable. ### Commitment boundaries Artificial systems can increasingly communicate externally, and external communication can create commitments. An agent may be authorised to draft a commercial response but not send it. It may schedule a meeting but not accept contractual terms. It may recommend a price but not publish it. It may prepare a public statement but lack publication authority. These are not cosmetic distinctions. Language changes state when other people are entitled to rely on it. ### Duration and revocation Authority exists in time. An envelope may apply to one task, one session, one change window, one incident or until a specified expiry. It should also be possible to narrow, suspend, supersede or revoke it. A delegation with no meaningful end condition is not automatically wrong, but long-lived authority deserves stronger justification than short-lived task authority. ### Subdelegation May the agent delegate any part of its authority onward? If yes, what limits survive the transfer? Subdelegation should normally narrow authority, not expand it. A child delegation should remain traceable to its parent, and authority derived exclusively from that chain should not outlive the chain that created it. ## Tools belong inside the envelope, not above it Tool permissions are often treated as the authority model because they are concrete and enforceable. This confuses mechanism with mandate. Suppose an agent has a cloud credential that can read and write a production database. The credential answers a useful question: what operations will the infrastructure accept? The authority envelope answers another: which of those operations are legitimate for this task? The relationship should therefore look roughly like: **technical capability ∩ delegated authority ∩ current conditions → legitimate action-space** The credential may be broader than the envelope. Sometimes that is unavoidable because external systems offer coarse permission models. In those cases, the governance layer has more work to do, not less. The agent must not treat the maximum reach of a credential as its own jurisdiction. ## An objective is not unlimited authority Objectives can be dangerously persuasive. “Resolve the customer's problem.” “Restore service.” “Prepare the launch.” “Reduce operating cost.” These sound specific until an agent begins finding adjacent actions that would help. Suppose the objective is to restore a failing service. The agent may legitimately restart an application, clear a bounded cache or roll back an approved release. During diagnosis it discovers that another team's database configuration is probably the underlying cause. The fact that changing that database would advance the objective does not bring the database inside scope. Useful is not the same as authorised. The envelope exists partly to prevent objectives from expanding themselves. ## Conditions can narrow authority without changing the objective An authority envelope should be sensitive to conditions that matter. An agent may be authorised to deploy while tests pass, the target commit matches the approved commit and the change window remains open. If a test fails or the approved artifact changes, the objective “deploy the release” may remain valid while the authority to execute the deployment no longer does. This allows a governed system to distinguish: - **the objective is still wanted** - **the planned action is still technically possible** - **the current conditions no longer satisfy the authority** That state should not be flattened into generic failure. It may require new evidence, another action inside the envelope or escalation for renewed authority. ## Boundaries should be machine-readable and human-legible A governance model fails if only one side can understand it. If an authority envelope is expressed solely as natural-language policy, the system may struggle to enforce it consistently. If it exists only as opaque machine rules, operators may be unable to understand why an action was allowed or denied. The ideal is not one universal syntax. It is a representation whose operative parts can be evaluated by the system and inspected by a person. For example: ```yaml principal: release-manager delegate: deployment-agent objective: deploy-release-2026-09-16 scope: repositories: [service-a] environments: [staging, production] actions: allowed: [read, test, deploy, rollback] prohibited: [change-access-control, alter-billing] constraints: production: require_tests: passed require_approved_commit: true change_window_ends: "17:00" external_commitments: none subdelegation: false revocable: true ``` The syntax is not the point. The inspectable boundary is. ## Authority should fail closed without becoming useless When a system cannot establish whether an action is inside its envelope, the safe answer is generally not to invent permission. But “fail closed” should not mean “give up on the task”. A governed agent can often continue useful work inside the surviving envelope. It can gather evidence, prepare a reversible change, draft a message, test a repair, identify the missing authority or produce an escalation packet. The boundary should constrain consequence, not abolish intelligence. This is one of the central design goals of governed agency: preserve as much useful initiative as possible without allowing initiative to silently become authority. ## Envelopes should compose carefully Real systems rarely contain one task and one authority source. An agent may operate under a standing organisational role plus a temporary incident grant. It may have base permission to inspect a repository and a time-bounded approval to deploy one release. A policy may permit an action while a customer-specific restriction prohibits it. These layers need a resolution rule. The simplest safe principle is that additional grants should not silently erase independent constraints. A temporary deployment authority does not cancel a data-handling policy. A user's request does not erase an institutional legal obligation. A local task grant does not necessarily outrank a system-wide prohibition. Where authorities conflict and no legitimate precedence rule resolves them, the conflict should remain visible. The agent should escalate the conflict rather than choose whichever source makes completion easier. ## The envelope is not a personality test A tempting shortcut is to govern agents through vague behavioural language: “be careful”, “use common sense”, “ask when unsure”, “act conservatively”. Those can be useful behavioural instructions. They are not an authority model. A cautious agent can still act outside its jurisdiction. A confident agent can still remain perfectly within it. Personality does not tell us who granted the authority, what was delegated, which resources are in scope or whether the grant is still valid. Governance should not depend on the agent having the right vibe. The envelope needs to remain true even when implementation, model or interface changes. ## The second law The first law separates capability from permission. The second gives permission a boundary: > **Permission should have an inspectable boundary.** That boundary should identify the principal, delegate, objective, scope, action classes, constraints, evidence requirements, duration, revocation conditions and subdelegation rules appropriate to the consequence involved. Inside it, the agent should be free to exercise legitimate judgement. Outside it, competence does not become permission merely because the next action is obvious. That is where the next problem begins.