Security review

AI agent security: the twelve questions your security review will ask about AI retrieval

The short answer. A security team approves an AI agent when the builder can show evidence for five things: who the agent acts for, what data it can reach for that person, what happens when access changes or a check fails, what is in scope and what isn't, and a record of every decision that an auditor can read and keep. The twelve questions below are the version we'd want handed to us before a review.

The twelve questions

  1. Does every request name the end user, not just the app?
  2. Is that user's identity verified, or only asserted by the app?
  3. Can the agent ever see more than the user could?
  4. Where is the permission check, and does it fail closed?
  5. Are the permissions the ones already defined in your sources?
  6. Is the vector store itself permission-aware?
  7. When someone loses access, when does the agent stop showing them that data?
  8. Can you test a permission before you ship it?
  9. Is every allow and every deny recorded, with the reason?
  10. Can the reviewer get those records out?
  11. Which sources, stores and apps are in scope, and which are not?
  12. How long are decision records kept, and who can read them?

Get the checklist with the evidence lines and the standards column (PDF).

What Gateco does

“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.”
  • Questions 1 to 3 and 9: each decision records the calling app or key, the end user, and whether that identity was verified.
  • Questions 4 and 6: Gateco checks what the index returns for that user before it becomes context, the same way on all 12 supported vector and search backends, and serves no chunk without a permission (deny by default). If the policy check itself fails, the retrieval is denied, unless the organisation has opted into fail-open with audit. Gateco applies authorization to the index's output, before it becomes context; it does not push a permission filter into the index query.
  • Question 5: permissions are imported from the sources and the identity provider. Notion is workspace-level only. There is no Teams connector.
  • Question 7: When a relationship is removed, the next retrieval is denied, on every instance: Gateco never serves a relation lookup from cache. For identity and source permissions, a change takes effect on the next retrieval after it reaches Gateco (see the questionnaire answer below).
  • Questions 8 and 10: the Access Simulator and JSON/CSV export are on Growth and above. No SIEM stream; the pricing page says “SIEM export (planned)”.
  • Question 11: the page names what isn't covered, as in question 5's bullet.
  • Question 12: decision records are kept for the life of the organisation; there is no automatic deletion and no retention setting today. They are readable by the organisation's signed-in users and exportable as JSON or CSV on Growth and above; API keys cannot read them.

A question from security questionnaires

“Do your AI features use retrieval-augmented generation (RAG), and how are access controls enforced on retrieved content?” (as worded in Wolfia's security questionnaire library)

Gateco enforces access at query time: every request is checked against the user's current groups, attributes and the active policies, and nothing is copied into the vector index. Identity changes arrive by SCIM push as they happen or by a sync the customer runs; permissions imported from Google Drive, SharePoint, Confluence or Notion are refreshed on each source sync, hourly, daily or on demand. A change takes effect on the next retrieval after it reaches Gateco.

Get the checklist with the evidence lines and the standards column (PDF).

Further reading: AI agent security review: a production checklist