AI agent security review: the checklist for moving agents to production

Approve the agent on proof, not a demo. Ten questions a security reviewer will ask, and what evidence answers each one.

The short answer. Security teams sign off on an AI agent when the builder can show evidence, not intent, for four things: who the agent acts for, what data it can reach on that person's behalf, what happens when access changes or a check fails, and a record of every decision that an auditor can read later. In the practitioner discussions and guides we've read, the second and fourth come up most often. The checklist below is the version we'd want handed to us before a review, with the evidence that actually closes each item.

Why pilots stall here

In early 2026, roughly half of agentic AI projects were still in proof-of-concept or pilot, and "security, privacy or compliance concerns" were the most-cited blocker, named by 52% of 919 senior leaders in Dynatrace's Pulse of Agentic AI 2026, just ahead of managing and monitoring agents at scale at 51% (SecurityBrief).

One failure reviewers worry about isn't a breach. It's the assistant that does exactly what it was built to do and still shows someone a document they shouldn't see. In a developer discussion on Reddit, one person made the point that vector search did exactly what it was asked, which isn't the same as checking who may see the result. Similarity doesn't know who is allowed to see what.

Reviewers also hold different agents to different bars. In one security vendor's guide, a read-only RAG assistant and an autonomous workflow agent "are reviewed against different evidence bars" (ARMO). This checklist focuses on the part almost every agent has in common: retrieving context on behalf of a user.

The checklist

Identity: who is the agent acting for?

1. Does every request name the end user, not just the app? An API key tells you which application asked. The reviewer wants to know which person the answer was for. Evidence: a log line per request showing both the calling app or key and the user it acted for.
2. Is that user's identity verified, or just asserted by the app? If the app can pass any user ID it likes, the permission check is only as strong as the app. Evidence: the record says whether the identity was verified for each request.
3. Can the agent ever see more than the user could? In that same Reddit discussion, one practitioner's bar was that an AI agent should never be able to do more than the user themselves could. Evidence: the agent's retrieval runs with the user's permissions, not a service account that can read everything.

Access: what data can it reach?

4. Where is the permission check, and does it fail closed? ISACA's 2026 guidance is direct: "Enforce authorization checks not only for tools, but also for memory retrieval and context access" (ISACA). Ask where that check lives and what the system returns when the check itself errors. Evidence: the check runs before context reaches the model, and an error means "deny", not "return everything".
5. Are the permissions the ones already defined in your sources? If the AI team hand-copies access rules into metadata filters, those rules drift from the real ones the day someone changes teams. Evidence: permissions come from the source systems and the identity provider, not a parallel list maintained by hand.
6. Is the vector store itself permission-aware? OWASP's 2026 list puts it plainly: "Apply access control at the chunk level: a mostly-public document can contain a confidential paragraph" (OWASP LLM09:2026). Evidence: every chunk that can be retrieved is tied to an owner and a permission, and chunks with no permission are not served.

Change: what happens when access changes?

7. When someone loses access, when does the agent stop showing them that data? This question often catches pilots out: the source permission changes, but the embeddings and filters don't. Evidence: a test that removes a user from a group, then shows the next retrieval is denied. Ask the vendor or your own team for the exact path and how long it takes to reach the AI layer, and don't accept a number nobody has measured.
8. Can you test a permission before you ship it? Evaluation guides recommend testing unauthorized access, including after permissions are removed (Handvantage). Evidence: a way to simulate "what would this user get for this query" without running it live.

Evidence: can you prove it afterwards?

9. Is every allow and every deny recorded, with the reason? In that same Reddit discussion, one commenter said their security reviewers asked what the assistant could have accessed last quarter. Evidence: per-decision records with who asked, for whom, what was allowed, what was denied, and why.
10. Can the reviewer get those records out? Logs that live only in a vendor console don't help an auditor. Evidence: export to a file, or a stream into the SIEM the security team already uses.

Where Gateco fits, and where it doesn't

Gateco covers the retrieval part of this list: items 1–10 as they apply to the context an AI application pulls from a vector store. It does not cover what an agent does with tools, prompt-level data loss, or the model itself; those need their own controls.

• Gateco is a separate authorization layer, enforced at retrieval time across the indexes and AI applications you already run, using the permissions already defined in your sources, with every decision recorded and exportable.
• Each retrieval is recorded with the caller (app, API key or console user), the person it was for, whether that person's identity was verified, the policy that applied, and the reason for any denial. Denied results carry no text. (items 1, 2, 9)
• Every retrieval is evaluated for a named end user: the request carries the user's identity, and the decision is made against that user's groups, attributes and relationships. An API key identifies the calling application only; a request with no user is rejected. (item 3)
• Retrieval is deny-by-default: a chunk with no matching permission is withheld: it comes back as a denial with the reason, never with its text. (items 4, 6)
• Permissions are imported from Google Drive, SharePoint and Confluence (Notion at workspace level), and users and groups sync from Okta, Microsoft Entra ID, AWS IAM Identity Center and Google Cloud Identity. (item 5)
• Policy changes apply at retrieval time with no re-embedding. When someone loses access, the next retrieval after the change reaches Gateco is denied. (item 7)
• The Access Simulator (Growth plan and above) shows what a given user would get for a query before anything goes live. (item 8)
• Decision records can be exported as JSON or CSV on the Growth plan and above. (item 10)
• Gateco works with 12 vector and search backends, including pgvector, Pinecone, Qdrant, Weaviate, Milvus, OpenSearch and Azure AI Search, through Python and TypeScript SDKs and an MCP server.

The Free tier is the fastest way to see what your own pipeline would record: every retrieval's decision record is there from the first call. The Access Simulator is on the Growth plan and above. For a design-partner pilot, write to pilots@gateco.ai.

Related: The RAG over-retrieval register · For security teams

Frequently asked questions

What does a security team need to approve an AI agent for production?

Evidence for four things: who the agent acts for, what data it can reach for that person, what happens when access changes or a check fails, and a per-decision record an auditor can read and export.

Why do AI agent pilots get stuck before production?

Security, privacy and compliance concerns were the most-cited blocker in Dynatrace's early-2026 survey. Often the gap is evidence: the pilot works, but the team can't show which data each user could reach or prove it after the fact.

Is a metadata filter in the vector database enough?

It can enforce a rule, but a reviewer will ask where the rule comes from, whether it matches the source permissions after people change roles, what happens when the filter errors, and where the record of each decision lives.

What should an AI audit log record for each retrieval?

Who asked (the app or key), who it was for, whether that identity was verified, what was allowed, what was denied, and the reason for each denial.