Skip to content

AGENTIC_BOUNDARY_MODEL.md

Latest commit

 

History

History
106 lines (74 loc) · 3.48 KB

AGENTIC_BOUNDARY_MODEL.md

File metadata and controls

106 lines (74 loc) · 3.48 KB
Raw

Agentic Boundary Model

Purpose

Use this template to document how an agentic repository controls high-risk actions.

This file is evidence for review. It is not a certification, production-readiness claim, AAIF affiliation claim, Linux Foundation affiliation claim, or endorsement claim.

High-Risk Action Boundary

Describe the action that needs governance.

Examples:

  • tool execution that can change external state
  • code generation that can be published or deployed
  • support answers that may reach customers
  • access or policy decisions
  • financial, identity, privacy, security, or data-export actions

Actors

Actor Responsibility
Human operator Owns approval and accountability.
Agent or assistant Proposes actions, drafts responses, or executes bounded tools.
Tool/runtime Performs scoped action and emits evidence.
Reviewer or auditor Reviews evidence, exceptions, and policy fit.

Identity Boundary

Document how identity is separated.

  • Who is the human accountable actor?
  • What tenant, workspace, account, or project scope applies?
  • What credentials or secret references are used?
  • Which actions may the agent propose but not approve?
  • Which actions require a human or policy-approved control?

Tool And Action Boundary

Action Boundary
read What data can be read and under what scope?
write What can be modified and how is the diff reviewed?
execute What commands/tools can run and where?
side_effect What external systems can change?
export What can leave the workspace and what scan/review is required?

Human Approval Gates

List actions that require explicit approval.

  • Before changing credentials, policies, roles, billing, deployment, or production data.
  • Before executing side-effecting tools against external systems.
  • Before sending generated content to customers or public channels.
  • Before adding or upgrading dependencies.
  • Before closing a security, audit, or compliance-relevant workflow.

Audit Event Model

Event Minimum Evidence
action.proposed actor, intent, tool/action, target, risk class
action.approved approver, action id, approval note, timestamp
action.executed tool, target, status, duration, sanitized output pointer
action.failed error class, retry status, owner, next step
action.reviewed reviewer, finding, exception, remediation

Local Proof Path

Document the strongest available validation path.

npm test

If runtime proof is blocked, record the blocker. Do not claim production readiness from static docs alone.

OSS And Self-Hosted Fallbacks

Document provider replacement paths.

  • Which paid providers are used?
  • Which open-source or self-hosted alternatives exist?
  • Which providers are behind adapters?
  • Which providers are mandatory today?
  • What cost, rate-limit, or data-residency constraints matter?

Evidence Checklist

  • Identity or actor boundary is documented.
  • Tool/provider/action boundary is documented.
  • Human approval or escalation point is documented.
  • Audit or observability events are documented.
  • OSS/self-hosted fallback direction is documented.
  • Local validation or static inspection path is documented.
  • Anti-claim language is present.

Contributor Follow-Up

List one small next contribution that would strengthen the evidence.

Example:

  • Add a fixture that records proposed action, approval state, execution status, and audit event reference.