Why your AI agent needs more than an IAM role

Two customers message your WhatsApp chatbot within minutes of each other. Customer A asks about their outstanding invoice. Customer B asks whether their premium support contract covers a recent issue. Your bot routes both queries to the same vector database. Both return semantically relevant results — because the knowledge base contains invoices and contracts for every customer. If the bot authenticates with a single IAM role, it can do one of two things: return everything to everyone, or return nothing. Neither is acceptable.

The wrong question

Most teams start here: "Should we give the bot access to this data?" That is an authentication question. Cloud IAM answers it — does this agent process have valid credentials to reach the API? Authentication is necessary. It is not sufficient. IAM tells you whether the bot can call your data infrastructure. It cannot tell you what any specific customer is allowed to see. That is an authorization question, and it operates at an entirely different layer.

IAM authenticates the agent. Gateco authorizes the data.

These are two distinct security concerns that operate at different points in the request lifecycle. Authentication answers "Is this WhatsApp bot a trusted caller?" — decided at the infrastructure boundary by cloud IAM roles, API keys, and network policy. Authorization answers "Can this specific customer see invoice #8421?" — decided at retrieval time by the policy engine, per result, per user.

A bot with a valid IAM role can serve thousands of customers simultaneously. IAM gives that bot one process identity. Without a per-request end-user principal, every retrieval runs under the bot's permissions — which means Customer A and Customer B see the same results. Policy enforcement requires knowing not just who called the API, but who is on the other side of the conversation.

Gateco fixes this by making the retrieval-time principal a request-scoped value, not a process-scoped one. The bot passes the current end user's identity on each query. Gateco resolves their permissions and filters results accordingly. IAM authenticates the process. Gateco authorizes the data.

This also matters across your whole agent stack. Gateco enforces tenant isolation at retrieval time even when multiple customers share the same agent runtime — one bot process, many customers, each seeing only their data.

Three integration patterns

Not every agent deployment has the same identity requirements. There are three distinct patterns, each suited to a different scenario.

Pattern 1: The bot as its own principal

The agent holds a Gateco Principal identity. Every retrieval runs as the bot. Setup: provision a service account in your identity provider, sync it into Gateco, and pass the bot's principal_id on each retrieval call.

This is right for public FAQ bots, anonymous assistants, or any deployment where user identity does not change what they are entitled to see. Every user receives the same filtered results — the bot's permission set. No per-user identity resolution required. Available today.

Pattern 2: The bot acting on behalf of an employee

The agent forwards a real employee's identity on each request. This is the pattern for internal tools: a Slack bot for sales reps, a Teams assistant for HR, a WhatsApp support channel used only by employees.

The bot resolves the employee by email and passes it to Gateco. The policy engine runs against their actual IDP-synced roles, groups, and department attributes. The MCP server integration makes this even simpler — the gateco_retrieve and gateco_ask tools accept an email parameter, so the agent passes the user's email and Gateco handles the rest. Available today.

Pattern 3: The bot acting on behalf of an external customer

The agent talks to people outside your corporate directory — WhatsApp customers, mobile app users, partner contacts. This is the canonical customer-facing chatbot scenario, and it is where most teams hit a wall.

Gateco's current identity model requires principals to originate from a connected identity provider. Supporting external customers properly — with channel-aware identity, inline attributes, and optional persistence — is on the roadmap. For now, the two workable interim approaches are: provision external users as guest accounts via SCIM, or pre-segment by tenant and give each customer cohort its own bot principal with narrow policies. The former is operationally expensive; the latter is coarser but clean.

What a governed retrieval looks like

To make this concrete, here is what a Pattern 3 retrieval will look like once external principals ship. A customer messages the WhatsApp bot: "Where is my order?" The bot authenticates to Gateco with its API key. The bot passes the customer's identifier as the external subject. Gateco resolves policy: this principal's channel is "whatsapp", their tenant_id is "customer_123", their kind is "external". The retrieval returns only documents where resource.tenant_id matches and resource.classification is public or below. The LLM receives policy-filtered context. The audit trail records channel, subject, and policy outcome.

The IAM call happens once at the process level. The Gateco policy evaluation happens on every request, for every user, with no additional code in the bot.

Where this leaves you today

Building an internal AI tool where users are employees in your IDP? Deploy Pattern 2 now. Connect your identity provider, pass the user's email on each retrieval, and your bot enforces your existing access policies automatically.

Building a public or single-audience bot? Deploy Pattern 1. Provision a service principal with narrow permissions.

Building a customer-facing multi-tenant product? Pattern 1 with tenant-scoped policies gives you isolation now. Pattern 3 will add true per-user policy enforcement when it ships.

If you are not sure which pattern fits your architecture, the contact page is the fastest path to a concrete answer. The full technical reference — SDK examples, policy conditions for agent flows, and audit trail details — is in the Agent Identity Patterns documentation.