Agentic AI security starts with what the agent can retrieve
The short answer. Most agentic AI security discussion is about what an agent can do: which tools it may call, which actions need a human to approve. For an agent working on enterprise data, a quieter question comes first: what can it read? Every answer, summary and action an agent produces starts from what retrieval put into its context. If retrieval hands it a document the person behind the request isn't allowed to open, no later control fully takes that back. Similarity search finds what is relevant. It doesn't decide who is entitled to see it.
Why agents make the retrieval question harder
A chat assistant is simple to reason about: one person asks, one search runs, one answer comes back. An agent changes three things.
- It writes its own queries. A task can trigger dozens of retrievals, with search terms nobody reviewed in advance. You can't secure the queries, so you have to secure what comes back.
- It usually retrieves with a service credential. The agent calls the search or vector service as an application, and that application can typically read far more than any single user. Unless something checks each result against the person the agent is working for, the agent reads at the service account's level and the person gets answers built from documents they could never open themselves.
- It runs over time. A task can take minutes or hours. People change roles, leave groups and lose access in the meantime. A permission check at the start of a task says nothing about a retrieval an hour later.
AI agent security risks at the retrieval layer
These are the risks a security reviewer will look for once an agent can search company data:
- Reading as the service account. The agent's results reflect what the application can see, not what the requesting person can see. This is the most common failure, and it happens by design rather than by attack.
- Mixing users. One agent serving a team channel, a shared cache or a shared memory store can carry one person's retrieved content into another person's answer.
- Permission changes mid-task. Access removed after the task started still shows up in results if nothing re-checks it.
- Side channels. Even without document text, scores, result counts and titles can reveal that a document exists. OWASP's 2026 LLM Top 10 treats raw similarity scores returned to the client as a membership oracle.
- Instructions hidden in retrieved content. A document the user is allowed to read can still carry text meant to steer the agent. That is a content problem, not a permission problem, and it needs its own controls.
- No record afterwards. When something goes wrong, nobody can say which documents the agent was allowed to read, for whom, and what was denied.
Two questions, two layers
It helps to separate two decisions that are easy to blur together:
- May this agent call this service at all? That is the job of your identity provider and agent identity platform, decided when the agent gets a credential.
- Which documents and chunks may come back, for the person this request is for? That is decided at retrieval, per document, every time.
A credential that lets an agent reach your search service is not an entitlement to every document in it. Both checks are needed, and they belong to different layers.
What a security reviewer will ask
| Reviewer question | Evidence that answers it |
|---|---|
| Whose permissions does the agent read with? | A record per retrieval showing the calling application and the user it acted for, and whether that identity was verified. |
| What happens when the permission check fails? | The check runs before retrieved content reaches the model; an error returns nothing, not everything. |
| Do the permissions match the source systems? | Permissions come from the sources and the identity provider, not a list someone maintains by hand. |
| What if someone's access changes mid-task? | A test: grant access, retrieve, revoke, retrieve again in the same session. The second retrieval should be denied. |
| Can a denied user infer anything? | What the application receives for denied content, and whether scores, counts or titles reach the end user. |
| Can you show afterwards what the agent was allowed to read? | Per-decision records of what was allowed, what was denied, and which chunks each decision covered. |
Where Gateco fits
A retrieval is authorized for the user the request names, never for the agent that makes it. By default the calling application asserts who that user is; when an organization turns on verified tokens, Gateco verifies it.
Gateco checks every candidate the index returns against the requesting user's permissions, withholds what is denied and, when denials leave the result set short, re-runs the search deeper to refill it, all before anything reaches the application or the model. So no unauthorized chunk becomes model context, and nothing relies on post-generation filtering. The permission check is one code path shared by all twelve vector and search backends Gateco supports, and it is deny-by-default. The permissions are the ones your organization already defines: groups and attributes from your identity provider, policies you write against them, and access lists imported from Google Drive, SharePoint, Confluence and Notion (Notion at workspace level). Every decision is recorded: what was allowed, what was denied, and the chunks each decision covered.
When an identity provider has not synced for more than 24 hours (configurable), Gateco adds a warning naming that provider to the retrieval response, and shows last sync time per source connection. (reliability details)
What Gateco does not cover. Gateco doesn't decide which tools an agent may call or which actions it may take; that belongs to your agent and identity platforms. It can't take back content that was already returned to an agent; it decides the next retrieval. And it doesn't detect instructions hidden in documents a user is allowed to read, or poisoned content in the corpus; those need content and ingest controls.
Common questions
What is agentic AI security?
The controls that keep AI agents, which plan and act across several steps, from doing or exposing more than they should. For agents that work on company data, that includes what they may read, not only what they may do.
What are the main AI agent security risks with enterprise data?
Reading at the service account's level instead of the user's, mixing users through shared caches or channels, permission changes during a long task, side channels such as scores and counts, instructions hidden in retrieved content, and having no record of what the agent was allowed to read.
If the agent has its own identity, isn't that enough?
An agent identity answers whether the agent may reach a service. It doesn't decide which documents in that service come back for the person the agent is working for. That second decision happens at retrieval.
Can filtering the agent's final answer fix an over-broad retrieval?
No. Once a chunk is in the model's context it can shape the answer, the agent's next step and any tool call it makes. OWASP's 2026 LLM Top 10 lists retrieval without permission checks as a vector and embedding weakness.
Where does this fit in the OWASP Top 10 for Agentic Applications?
Closest is ASI03:2026, Identity and Privilege Abuse. One example OWASP gives is permissions that are "validated at the start of a workflow but change or expire before execution." Its examples are about actions; the retrieval side of the same risk is an agent reading with access the person behind the task doesn't have, or no longer has. That part is decided per document, for the person the request is for, on every retrieval. The rest of ASI03, such as scoped agent credentials, delegation between agents and human approval for privileged actions, belongs to your agent and identity platforms.
If your agent pilot is heading into a security review, the twelve questions we'd want answered first go further on retrieval.
If you have an AI pilot waiting for security sign-off, start free.
Sources
- OWASP Top 10 for LLM Applications 2026: LLM09:2026 Vector and Embedding Weaknesses, GenAI-Security-Project/GenAI-LLM-Top10 on GitHub.
- OWASP Top 10 for LLM Applications 2026: LLM02:2026 Sensitive Information Disclosure, same repository.
- OWASP Top 10 for Agentic Applications 2026: ASI03:2026 Identity and Privilege Abuse, OWASP GenAI Security Project (PDF).
Related reading
Ready to secure your AI retrieval?
Start with the free tier: 1,000 retrievals/month, no credit card required.