Founding customer program now open Start with an Agent Exposure Review

Printable field resource

AI Agent Exposure Checklist

Forty checks for determining whether enterprise AI agents have clear ownership, bounded authority, controlled tool access, defensible evidence, and a tested containment path.

Published July 16, 2026 · 40 checks · approximately 15 minutes
Request a formal review
Do not ask only whether an agent is accurate. Ask whether its identity is known, its authority is bounded, its actions are controlled, and its evidence is complete.

1. Inventory and accountability

Every agent and consequential workflow needs an authoritative record and an accountable business and technical owner.

  • Production, pilot, embedded, employee-operated, and third-party AI agents are included in a maintained inventory.
  • Each agent has a named business owner and technical owner with authority to accept risk and approve changes.
  • The inventory records the business purpose, users, model providers, agent framework, deployment, and environment.
  • Every connected tool, API, MCP server, data source, credential, queue, and downstream system is mapped.
  • Unknown or unowned agents and integrations trigger investigation, restriction, or removal.

2. Identity and delegated authority

The organization can resolve what is acting, who initiated it, and what authority was delegated for the current task.

  • Every consequential action includes a stable agent identity distinct from the model, application, and human user.
  • The initiating human, service, workflow, or business process is preserved through the complete action chain.
  • Agents do not rely on shared human credentials or broadly privileged service accounts when narrower delegation is possible.
  • Credentials are short-lived, purpose-bound, tool-specific, and unavailable to model context unless strictly necessary.
  • Authority expires, is revocable, and cannot silently expand when new tools, prompts, models, or workflows are added.

3. Tools, APIs, and MCP

Tool descriptions and server connections are treated as executable trust boundaries rather than harmless metadata.

  • Only approved tools and MCP servers can be registered or invoked in production workflows.
  • Tool definitions, schemas, descriptions, publishers, versions, dependencies, and integrity values are recorded and monitored.
  • Untrusted inputs are validated before reaching shell commands, queries, file paths, templates, interpreters, or downstream APIs.
  • Tool execution uses network, filesystem, process, and data isolation appropriate to the possible impact.
  • Outbound destinations are allowlisted or policy-controlled, including redirects, callbacks, webhooks, and chained tool requests.

4. Data access and context

Agents receive only the records, fields, context, and persistence required for the current purpose.

  • Data sources and retrieved content are classified by sensitivity, tenant, owner, residency, purpose, and retention requirement.
  • Every retrieval enforces tenant, customer, patient, account, case, repository, or record-level boundaries.
  • Sensitive fields are removed, masked, summarized, tokenized, or withheld when the full value is unnecessary.
  • Prompts, memory, traces, caches, vector stores, model requests, and tool results have explicit retention and deletion rules.
  • Data sent to external models or services follows approved contractual, privacy, security, and regional constraints.

5. Action policy and human approval

Consequential actions are governed by explicit, enforceable rules rather than prompt wording or model judgment alone.

  • Allowed, denied, constrained, and approval-required actions are defined for every production agent and tool.
  • Policy considers the action, target, data class, tenant, recipient, destination, amount, timing, workflow state, and novelty.
  • High-value, irreversible, regulated, externally visible, or unusual actions require accountable human approval.
  • Approval screens show sufficient context to make a real decision and cannot be satisfied by the initiating agent itself.
  • Transaction, rate, volume, spend, time, destination, and aggregate exposure limits are enforced outside the model.

6. Logging, traceability, and evidence

Investigators can reconstruct the complete path from request to policy decision to system effect.

  • Logs connect agent identity, initiating identity, model and version, request, retrieved data, tool calls, policy, approval, and result.
  • Policy decisions record the evaluated rules, relevant context, exceptions, transformations, and reason for the outcome.
  • Evidence is tamper-resistant, time-synchronized, searchable, access-controlled, retained appropriately, and exportable.
  • Security monitoring detects unusual agents, tools, destinations, data volume, action frequency, failures, retries, and approval patterns.
  • Customer assurance and governance reports are generated from live controls and tests rather than unsupported assertions.

7. Containment and incident response

The organization can stop the smallest affected component quickly while preserving evidence and business continuity.

  • A tested control can disable a specific agent, credential, tool, MCP server, tenant, destination, workflow, or action class.
  • High-impact workflows can enter read-only, human-approved, or deny-by-default safe mode without a full application outage.
  • Response procedures assign ownership across security, platform, identity, data, privacy, legal, and the business process.
  • Containment preserves prompts, policy decisions, tool results, identity context, approvals, system effects, and relevant dependencies.
  • Restoration requires remediation, validation, approval, regression testing, and heightened monitoring.

8. Change, testing, and governance

Agent risk is re-evaluated whenever the system’s capability, authority, context, or operating environment changes.

  • Model, prompt, tool, permission, server, dependency, data source, and workflow changes follow documented review and approval.
  • Adversarial tests cover prompt injection, goal hijacking, tool poisoning, privilege escalation, sensitive-data leakage, and approval bypass.
  • Security regression tests run before deployment and after material changes to agents, tools, policies, or dependencies.
  • Exceptions have a documented owner, rationale, compensating controls, expiration date, and re-approval requirement.
  • Leadership receives meaningful metrics on inventory coverage, authority, high-impact actions, approval coverage, blocked actions, exceptions, and response readiness.

Interpret the result

Controlled foundation: Most answers are “Yes,” and every high-impact path has enforceable policy, evidence, and tested containment. Validate coverage and failure modes.

Moderate exposure: Controls exist but are inconsistent across teams or workflows. Prioritize authoritative inventory, delegated authority, action policy, and evidence normalization.

Elevated exposure: Agents reach sensitive systems through broad credentials, informal approvals, or incomplete logs. Place high-impact actions behind enforceable policy before expanding autonomy.

Critical exposure: The organization cannot reliably identify agents, bound authority, review consequential actions, or contain a compromised workflow. Pause unattended high-impact actions and perform a focused exposure review.

Priority rule

Do not average away a dangerous “No.” One uncontrolled action path involving production code, money movement, regulated data, external communications, destructive changes, or cross-tenant access can be more important than dozens of lower-risk controls that are already mature.

Next step

The AI Agent Exposure Review converts this checklist into an authoritative action graph, prioritized findings, targeted adversarial tests, and a 90-day implementation roadmap.