Approving an AI agent is not the same as approving another productivity application. Agents can interpret goals and take a sequence of actions with limited supervision.
That autonomy can be timesaving, but it also extends the consequences of mistaken instructions, excessive permissions, compromised integrations, and prompt injection. Before deployment, users must understand what the agent will be technically capable of doing.
The following seven questions provide a practical checklist for evaluating AI agent security before granting access to company systems and data.
1. What specific task will the agent perform?
Start with a defined business outcome. “Improve productivity” or “assist employees” is too broad to establish safe boundaries. A useful scope might be summarizing approved internal documents, creating service-desk tickets, or drafting code changes for review.
Identify the process owner, intended users, systems, and measures of success. Document what sits outside the agent’s purpose. A support agent that retrieves knowledge-base articles should not also change customer records or reset credentials.
Clear purpose supports least agency: giving an agent only the autonomy, tools, and permissions necessary for its assigned task. It also creates a baseline for testing whether the agent stays on task after deployment.
2. What data can the agent access?
Know which data enters the agent’s context, where it is processed, and whether prompts, outputs, or retrieved content are retained. Include email, collaboration platforms, browser sessions, shared drives, logs, and agent memory.
Map access by repository and data classification. Separate permission to search from permission to copy, modify, upload, or delete. An agent that needs a product catalog should not automatically receive customer records. An agent that reads a user’s files should not inherit access to every employee’s files through a shared service account.
Ask how data is isolated among users, tenants, and sessions. Enforce access at the storage or application layer so a prompt alone cannot expose sensitive information.
3. Which tools and actions can the agent use?
An agent’s practical risk is shaped by its tools. Read-only search presents a different exposure from shell access, code execution, email delivery, purchasing, file deletion, or configuration changes.
Inventory every tool, plugin, API, application, and child process the agent can invoke. Distinguish read, write, execute, send, delete, and administrative capabilities. Avoid open-ended tools when a narrower function will do.
OWASP identifies excessive functionality, permissions, and autonomy as root causes of excessive agency. Its guidance recommends limiting agents to necessary extensions and enforcing minimum permissions in downstream systems.
It is important to firmly establish whether the agent needs that tool and what the tool permits the agent to do.
4. Which identity and credentials will the agent use?
An agent should be distinguishable from the human or service directing it. If it signs in with a shared administrator account or reuses a person’s credentials, the organization may struggle to determine who—or what—performed an action.
NIST advises treating agents as distinct entities with their own identifiers, credentials, and entitlements, bound to the user or system operating them. NIST also warns that shared credentials, static tokens, and broad API keys weaken accountability and granular authorization.
Confirm that credentials are unique, scoped, short-lived, and revocable. Determine whether the agent can exceed the requesting user’s authority. Plan for rotation, expiration, incident revocation, and decommissioning.
5. What actions require human approval?
Not every step needs to be reviewed. Requiring human-in-the-loop (HITL) approval for routine searches or drafts can create friction and encourage users to approve prompts mechanically. Intervention should follow consequence.
Require approval before actions that are sensitive, externally visible, privileged, financially binding, difficult to reverse, or capable of disrupting operations. Examples include sending communications, publishing content, executing code, deleting data, transferring sensitive files, making purchases, changing configurations, or elevating privileges.
The reviewer should see the exact action, target, data, destination, privilege, and expected result. Approval should apply only to that request. OWASP recommends verifying authorization outside the agent’s context and binding it to the precise tool, so changed parameters or repeated requests require fresh approval.
6. Can every action be monitored and attributed?
Approval should depend on evidence that the organization can reconstruct what happened. Logs should connect the initiating user, agent identity, prompt or task, data sources, tool calls, approval decisions, policy results, system changes, and outcome.
Ask where logs are stored, how long they are retained, whether they can be altered, and how they integrate with security monitoring. Endpoint and network telemetry should reveal processes, file access, privilege use, and connections outside the agent platform.
Monitoring does not replace prevention. It verifies that boundaries continue to work and helps teams detect unusual sequences, investigate incidents, refine policy, and demonstrate accountability.
7. What limits the damage if the agent behaves unexpectedly?
Assume the agent will eventually encounter ambiguous instructions, malicious external content, a failing integration, or a condition its designers did not anticipate. Ask how the system fails.
Strong answers include deny-by-default policies, isolation, rate and spending limits, restricted destinations, rollback, rapid credential revocation, and a tested stop mechanism. Teams should be able to contain one agent without disabling the entire process.
Test before production using representative workflows and adversarial inputs, including indirect prompt injection, unauthorized tools, privilege escalation, and high-volume actions. Reassess whenever the agent’s model, tools, purpose, integrations, or access changes.
Zero Trust policies turn approval criteria into technical controls
A completed questionnaire does not constrain an agent. The approval decision must become enforceable policy across every application and process the agent uses.
- Application Allowlisting can restrict which executables and scripts are permitted to run.
- Ringfencing™ can control how approved applications interact with files, other applications, system components, and network resources.
- Privileged Access Management can remove standing administrative rights and govern elevation.
- Data Storage Access Control and Endpoint Firewall can restrict sensitive data access and connections.
These controls help organizations define what an approved agent workflow can execute, access, elevate, and connect to. Detection and audit telemetry then provide evidence that the boundaries remain effective.
An AI agent should be approved for a specific job, not granted general trust. CISOs and buyers should know its purpose, data, tools, identity, approval points, audit trail, and containment plan before enabling it.
If any answer remains vague, narrow the deployment until the organization can enforce and verify the boundary.
Frequently asked questions
Who should approve an AI agent?
Approval of AI agents should involve the business owner, security team, system or data owners, and compliance stakeholders relevant to the use case. Procurement alone cannot validate technical access and operational consequences.
Should AI agents use employee credentials?
Agents should generally use distinct, scoped identities rather than shared or copied employee credentials. Delegated access should preserve the requesting user’s context while keeping agent activity identifiable and independently revocable.
How often should an approved AI agent be reassessed?
Reassess AI agents and approvals periodically whenever the purpose, model, permissions, tools, integrations, or data access changes. Security incidents and unexpected behavior should also trigger immediate review.
