Use the AI agent boundary register lite model to document agent owners, allowed actions, blocked actions, tool access, escalation paths, and shutdown routes.
An AI agent boundary register documents the operational boundary around an agent: owner, purpose, allowed actions, blocked actions, tool access, data access, escalation trigger, containment path, and review cadence. It is one of the first evidence artifacts a CISO or AI governance owner needs before approving agentic AI use.
| Lite field | What to document | Why it matters |
|---|---|---|
| Agent identity | Name, environment, owner, business process, deployment status. | Prevents orphaned or unowned AI agents. |
| Allowed actions | Actions the agent may perform without additional approval. | Clarifies the approved operating boundary. |
| Blocked actions | Actions the agent must not perform, even if technically possible. | Creates a reviewable governance constraint. |
| Tool and data access | Connected tools, APIs, repositories, credentials, data classes, and external systems. | Connects governance to runtime exposure. |
| Escalation and shutdown path | Human owner, escalation trigger, containment action, incident owner, review cadence. | Reduces confusion when the agent behaves outside expectations. |
Download the lite CSV field list to start an internal register. The CSV is a starter model, not the full ACT-2 agentic AI governance module.
Download lite CSVNo accountable owner exists for reviewing agent behavior, approving tool access, or responding to incidents.
The agent can access tools, repositories, APIs, or systems without a documented approval boundary.
The team has not defined when to pause, contain, disable, or escalate an agent that behaves outside expectations.
The lite register gives a field model. ACT-2 extends the concept into a broader agentic AI governance evidence set. M78Armor is relevant when the operating question becomes technical hardening for OpenClaw, Hermes, MCP, or similar local AI-agent deployments.
An AI agent boundary register is a governance record that documents what an AI agent may do, which tools it may access, which actions are blocked, who owns the agent, and when human escalation or shutdown is required.
The AI agent boundary register is governance evidence, not a technical security control by itself. Technical enforcement may require identity controls, tool permissions, logs, runtime restrictions, secure configuration, and hardening work outside the register.
The AI agent boundary register connects to ACT-2 as governance evidence and to M78Armor where OpenClaw, Hermes, MCP, or local AI-agent runtime hardening is relevant. ACT-2 organizes evidence; M78Armor is the technical hardening route.
Source and review note: This page was last reviewed on 6 May 2026 against the current Move78 public site baseline and relevant official or authoritative sources where laws, standards, frameworks, cybersecurity controls, product scope, pricing, support policy, or implementation guidance are discussed. It provides operational implementation guidance and product information only; it is not legal advice, tax advice, audit assurance, certification assurance, conformity-assessment advice, buyer-approval assurance, or security assurance. Validate legal, regulatory, contractual, tax, audit, and security decisions with qualified professionals.