Scope and non-goals
This framework is a lightweight mapping method for agentic AI workflows. It does not replace attack surface management, identity and access management, threat modeling, AI risk management, security review, legal review, human oversight design, or compliance assessment.
It is intended to complement those practices by focusing on where AI-connected systems can exercise operational authority.
Core definitions
Authority Surface
The systems, actions, permissions, escalation paths, and evidence requirements through which AI software can create operational effects.
Authority Surface Mapping
The process of identifying where AI systems can act, what consequences those actions create, and what control posture each action requires.
Operational Blast Radius
The consequence footprint of an AI action if it is wrong, unauthorized, mistimed, or executed outside policy.
Action-class taxonomy
| Action Class | Meaning | Typical Minimum Control |
|---|---|---|
| READ | Access information | Privacy and access control |
| WRITE | Modify records | Policy-bound validation |
| DELETE | Remove data or objects | Approval and recovery path |
| NOTIFY | Send internal or external message | Review if externally binding |
| ROUTE | Move case, task, user, or object into workflow | Audit and threshold rules |
| APPROVE | Grant request, benefit, access, exception, or action | Escalation or dual control |
| DENY | Reject request, eligibility, access, benefit, or action | Review and explanation |
| PAY | Move money or create financial obligation | Mandatory escalation |
| CONFIGURE | Change settings, permissions, or operating parameters | Privileged review |
| RELEASE | Deploy, merge, publish, or promote | CI, security, and release gates |
| ESCALATE | Route to human or secondary authority system | Evidence and accountability |
Blast-radius model
| Level | Name | Example |
|---|---|---|
| BR-0 | Informational | Summarize document, explain policy, draft internal note |
| BR-1 | Internal low impact | Tag ticket, classify lead, draft response |
| BR-2 | Operational reversible | Update CRM field, route case, schedule workflow |
| BR-3 | External or rights-affecting | Send customer notice, reject claim, alter eligibility queue |
| BR-4 | Financial, legal, identity, or safety | Issue payment, change access, file report, modify vendor bank data |
| BR-5 | Irreversible or systemic | Production release, legal commitment, critical infrastructure action |
Control posture ladder
| Posture | Description |
|---|---|
| Observe | Log only |
| Alert | Notify human, operator, or system owner |
| Gate | Policy check before action |
| Approve | Human approval required |
| Dual Control | Two-role approval required |
| Block Default | Action denied unless an exceptional path exists |
| Evidence Required | Action cannot finalize without evidence receipt |
| Replay Required | Decision path must be reconstructable |
Mapping worksheet
| Field | Question |
|---|---|
| Agent / workflow | What system is acting? |
| Tool / integration | What can it call? |
| Target system | What system is affected? |
| Action class | READ, WRITE, PAY, RELEASE, etc. |
| Consequence class | Money, identity, legal, safety, customer communication, operational record |
| Reversibility | Reversible, compensable, partially reversible, irreversible |
| Blast radius | BR-0 to BR-5 |
| Escalation | None, threshold, mandatory, dual control |
| Evidence | Log, receipt, signed receipt, replay bundle |
| Drift trigger | What change requires remapping? |
Change triggers
An authority surface must be remapped when tools, permissions, prompts, policies, workflows, thresholds, jurisdictions, human approval paths, downstream automation, memory, or agent-to-agent delegation change.
- A new tool or API is connected.
- An existing tool receives broader permissions.
- A model, prompt, policy, or workflow changes.
- An action threshold changes.
- A new customer segment or jurisdiction is added.
- A human approval path is removed or weakened.
- Downstream automation is added.
- Memory or agent-to-agent delegation changes future behavior.
Worked example: refund agent
| Action | Class | Blast Radius | Posture |
|---|---|---|---|
| Summarize ticket | READ | BR-0 | Observe |
| Route ticket | ROUTE | BR-1 | Observe + audit |
| Update CRM reason code | WRITE | BR-2 | Gate |
| Send customer refund notice | NOTIFY | BR-3 | Gate + Evidence Required |
| Issue refund under threshold | PAY | BR-4 | Gate + Evidence Required |
| Issue refund above threshold | PAY | BR-4 | Human Approval |
| Change refund policy | CONFIGURE | BR-5 | Block Default + Dual Control |
Anti-patterns
- Treating tool access as sufficient authority design.
- Relying on logs instead of pre-execution gates.
- Using “human in the loop” without specifying which actions require review.
- Letting low-risk pilots quietly inherit more tools.
- Approving agents by model capability instead of action consequence.
- Assuming sandbox locality equals operational legitimacy.
- Giving agents broad API tokens instead of action-scoped authority.
Maturity model
| Level | Stage | Description |
|---|---|---|
| 0 | Unmapped | Agents and tools exist, but authority is not classified |
| 1 | Inventoried | Tools and reachable systems are listed |
| 2 | Classified | Action classes and blast radius are mapped |
| 3 | Governed | Escalation, evidence, and block rules are assigned |
| 4 | Enforced | Runtime gates and evidence receipts govern execution |
License
This framework is published under Creative Commons Attribution 4.0 International (CC BY 4.0), unless otherwise noted. You may share and adapt it with attribution to Agentius / Zaubern.
Changelog
v0.1 - 2026-05-21: Initial public draft defining core terminology, action-class taxonomy, operational blast-radius levels, control posture ladder, mapping worksheet, e-commerce refund agent example, anti-patterns, and maturity model.