Open-Source Framework · Agent Governance

The Autonomy Boundary

Every organization deploying AI agents establishes a boundary between autonomous action and human authorization. In most deployments that boundary is implicit — distributed across prompts, configuration, and unreviewed code. The Autonomy Boundary Framework defines that boundary explicitly, enforces it at runtime, and produces evidence of where it was drawn.

Seven Controls Across Three Lifecycle Phases

Select a control for its definition.

Contextuntrusted input
Agentdecides & acts

Autonomy boundary — the leader's call, not the model's

Before acting

At the boundary

After & continuous

Real systemsrecords · finance · ops
Start here

Context is untrusted input; the agent is capable; downstream systems are consequential. The boundary is the enforcement point that determines what crosses.

Reference

Control Reference

Each control addresses a question that arises in post-incident review and audit.

01

Scope

Before acting

What the agent is permitted to access — enumerated, not inferred. The characteristic failure is treating capability as permission: possession of a shell interpreted as authorization to use it.

Absent this control: blast radius defaults to whatever the credentials permit.

02

Authority

Before acting

Whose authority the agent acts under. Every action inherits a named individual's authority and carries it forward; actions without inherited authority do not execute.

Absent this control: post-incident review cannot establish who authorized which action.

03

Input integrity

Before acting

Whether consumed context can be trusted. Retrieved documents, web pages, ticket comments, and file names are data — not instructions — regardless of phrasing.

Absent this control: any party able to write into the context window can direct the agent.

04

Reversibility

At the boundary

Whether the action can be reversed. This control determines gate placement: irreversible actions receive human review; reversible actions proceed. Universal gating conditions reviewers to approve reflexively, which is operationally equivalent to no gating.

Absent this control: approval fatigue degrades the gate until it provides no assurance.

05

Legibility

At the boundary · the distinctive one

Approved must equal authorized. The action reviewed in the approval dialog must be the action that executes. The two diverge more readily than commonly assumed — through shell expansion, symlinks, tool chaining, and late binding between the moment of approval and the moment of execution.

NIST CAISI, OWASP ASI, CSA MAESTRO, ISO 42001, Microsoft ACS, and Google SAIF 2.0 each address aspects of agent governance; none isolates this control by name. It is the framework's primary contribution.

Absent this control: the audit trail records approvals that never corresponded to the executed actions.

06

Observability

After & continuous

Whether agent activity is visible during execution. Reconstructing intent from application logs after the fact is forensics, not observability.

Absent this control: failures surface through customer impact rather than internal detection.

07

Provability

After & continuous

Whether outcomes can be demonstrated after the fact to an independent party — an auditor, a regulator, or counsel. This requires a tamper-evident record rather than an administrator-editable log.

Absent this control: the organization holds an account of events, not evidence.

Implementation

Reference Implementation

The repository is deliberately compact and dependency-free — Python standard library only — so it can be fully reviewed and executed without installation overhead.

What's in it

  • intent_binding.py — binds an approval to the exact action it authorized, so the two cannot drift apart before execution
  • ledger.py — a hash-chained, tamper-evident record of what was authorized and what ran
  • THREAT_MODEL.md — what this defends against, and explicitly what it does not
  • README.md — the framework, the controls, and how to run the demos

Community Review

  • Referenced by security practitioners in banking and AI infrastructure, with field design contributions credited in the repository
  • State admissibility — a proposed eighth control, on whether the state an agent observed was itself trustworthy
  • Semantic binding — whether intent survives shell expansion, symlinks and tool chaining
  • Approval provenance — countersigning at write time rather than at approval time

What this is not. It does not replace NIST CAISI, OWASP ASI, CSA MAESTRO, ISO 42001, Microsoft ACS or Google SAIF 2.0, and it is not a compliance certification. Those frameworks operate at the level of programs and organizations. This one operates at the level of a single action crossing a boundary at runtime, which is where the failures I have actually had to explain to auditors occur.

The repository, including issues and design discussion, is public at github.com/hoomanp/autonomy-boundary.

Provenance

Grounded in Audit-Grade Operations

This framework draws on twelve years operating cloud platforms under PCI-DSS, HIPAA, SOC 2, SOX, and NIST, and four years owning AI security at Microsoft for services carrying over one billion sessions per month. The governing observation from that experience: in regulated operations, the operative question is not whether a system was secure, but whether that can be demonstrated.

Most agent-governance work concentrates on preventing adverse outcomes. The harder requirement — and the one auditors, regulators, and counsel ultimately impose — is producing evidence after the fact. Legibility and provability hold first-class positions in this framework for that reason.

Related analysis is available under Publications; additional technical work is documented under Case Studies.

Contact

Framework & Advisory Inquiries

Technical review, implementation questions, and advisory inquiries regarding agent governance in regulated environments are welcome.