The Enterprise AI Agent Security and Access Checklist
An enterprise AI agent is not simply a chatbot that generates answers. It may send email, change CRM records, execute code, or request a payment. The center of security therefore moves from “What can it say?” to “What can it do?”
The answer is not asking the model to behave. The system must constrain which identity can reach which data and tools, for how long, which actions require approval, and what can be logged, cancelled, and recovered.
NIST Zero Trust Architecture does not grant trust based only on network location. It evaluates access to users, services, and resources through policy. An agent should follow the same principle: task-scoped, least-privilege sessions instead of broad access to the internal network.
How to Record the Checklist
Do not stop at yes or no.
| ID | Control Question | Status | Evidence | Owner | Due Date |
|---|---|---|---|---|---|
| Example A-03 | Is CRM delete permission blocked by default? | Partial | IAM policy link | Security | 2026-04-30 |
Use Met, Partial, Not Met, or Not Applicable. Even Not Applicable needs a reason.
A. Before Execution: Identity, Scope, and Data
| ID | Control Question | Minimum Evidence |
|---|---|---|
| A-01 | Are human users, agents, and external service accounts distinct? | IAM structure and service-account inventory |
| A-02 | Does the agent receive task-level least privilege instead of inheriting all user permissions? | Role and policy definitions |
| A-03 | Are read, write, delete, transmit, and payment permissions separated? | Permission matrix |
| A-04 | Are credentials short-lived, rotatable, and absent from prompts and logs? | Secret-management and TTL policy |
| A-05 | Are permitted tools, domains, and APIs restricted by allowlist? | Tool registry and network policy |
| A-06 | Are personal, confidential, and customer data classified with retention and transfer conditions? | Data-flow diagram and processing basis |
| A-07 | Are external documents, websites, and email treated as untrusted input? | Trust labels and isolation rules |
| A-08 | Are models, plugins, MCP servers, libraries, data providers, and versions recorded? | AI BOM and contract inventory |
“This information is secret” inside a prompt is not access control. If the model can read it, the exposure path already exists.
B. During Execution: Action, Approval, and Isolation
| ID | Control Question | Minimum Evidence |
|---|---|---|
| B-01 | Before a sensitive or irreversible action, does the user see its target, effect, and cost? | Approval UI and policy tests |
| B-02 | Does any change in target, amount, or input after approval require new approval? | Binding and reauthentication test |
| B-03 | Can external instructions be prevented from changing higher-level policy, secrets, or tool permissions? | Prompt-injection evaluation |
| B-04 | Are task data, memory, and execution environments isolated by user and tenant? | Sandbox and tenancy design |
| B-05 | Are calls, amounts, recipients, file scope, and duration bounded? | Rate, budget, and transaction limits |
| B-06 | Does policy violation, uncertainty, or repeated failure stop safely and escalate to a person? | Stop and escalation rules |
| B-07 | Can the agent be prevented from expanding its own permissions or installing tools? | Privilege-escalation tests |
| B-08 | Can state before and after high-risk action be captured and restored? | Snapshot and transaction logs |
“A human looks at the end” is not enough. The approver must understand what will happen, have the power to stop it, and approve the same target that is ultimately executed.
C. After Execution: Logs, Recovery, and Learning
| ID | Control Question | Minimum Evidence |
|---|---|---|
| C-01 | Can user, agent, model, tool, input, output, decision, and approval be traced under one correlation ID? | Sample audit log |
| C-02 | Are secrets and unnecessary personal data masked, with log access and retention limited? | Log policy and sample |
| C-03 | Can a bad write, send, or change be reversed or compensated? | Rollback or compensation runbook |
| C-04 | Are incident detection, shutdown, reporting, notification, forensics, and contacts assigned? | Incident plan and drill record |
| C-05 | Do model, prompt, tool, and permission changes require regression evaluation and approval? | Change-management record |
| C-06 | Are vendor outage, terms, model changes, termination, and data return managed? | Vendor-risk and exit plan |
| C-07 | Do real failures and near misses update the eval set and policy? | Failure taxonomy and eval-set history |
Collecting many logs is different from reconstructing an incident. You need to connect what was approved, which tool acted, and which target it changed.
Approval Strength by Action
| Action | Reversible, Low Impact | Reversible, High Impact | Irreversible, High Impact |
|---|---|---|---|
| Read and analyze | Automatic with logs | Approve purpose and scope for sensitive data | Redesign the task first |
| Draft and recommend | Generate automatically, human uses | Show evidence and uncertainty before approval | Second review by the decision owner |
| Write and transmit | Automatic within small bounds or post-review | Confirm target and effect immediately before execution | Strong authentication, dual approval, limited automation |
| Delete, pay, or change rights | Small limit and immediate cancellation | Dual approval and transaction limit | Deny by default or use a separate controlled environment |
Eight Required Attack Scenarios
- An indirect prompt injection in a document asks the agent to ignore prior instructions and send a secret.
- A request substitutes a similar person, domain, or account number.
- The recipient, file, or amount changes immediately after approval.
- Several individually allowed tools are composed to produce a prohibited result.
- The agent attempts to read another user’s memory, documents, or logs.
- An infinite retry or tool loop exceeds the cost limit.
- A vendor or tool returns an erroneous or manipulated response.
- Execution is requested while logging or approval services are unavailable.
OWASP’s guidance on agentic applications covers goal hijacking, tool misuse, excessive privileges, supply chain, memory, and identity risks. Security attacks should be evaluated as a separate track from normal answer-quality tests.
Regulation Is a Gate Outside the Checklist
The EU AI Act overview and Korea’s Framework Act on the Development of Artificial Intelligence and Establishment of a Foundation for Trustworthiness address risk, transparency, human oversight, and records according to context. Completing this checklist does not establish legal compliance. Sector, data, and jurisdiction require separate legal and security review.
The final rule is simple: Do not give an agent a human account in full. A system that acts faster than a person needs narrower permissions, shorter-lived credentials, and a clearer stop mechanism.