Your AI Agent Needs an Identity, Not a Shared API Key

AI agents are moving from answering questions to reading customer records, updating tickets, issuing refunds and calling internal tools. That changes the central security question. It is no longer only “Is the model safe?” It is “Whose authority is the agent using for this action?”

On 19 August 2026, AWS published a reference architecture for carrying a user’s authorization context through an AI agent to databases, knowledge bases and external SaaS systems. The most useful principle is vendor-neutral: the agent should orchestrate work, but it should not become the final gatekeeper for data access.

This matters to Gulf organizations turning AI pilots into operational systems. A shared assistant may serve sales, finance, operations and support through one interface. If every request runs under one broad service credential, a prompt-injection flaw, mistaken tool choice or application bug can expose far more than the requesting user is allowed to see.

Authentication is not authorization

Authentication proves who initiated a request. Authorization decides what that identity may do, to which resource, under which conditions. Many agent prototypes authenticate the employee at the chat interface, then discard that identity when the agent calls a tool. Every downstream request is made with the agent’s shared credential.

That design creates a privilege inversion: the human may have limited access, while the agent acting for that human has broad access. The application then tries to repair the gap with prompt instructions or query filters. Neither is a durable security boundary.

A safer flow preserves relevant user claims—such as role, department, project, geography and approval level—through every hop. Infrastructure and downstream services evaluate those claims independently. The agent can request an action; it cannot grant itself permission.

The architecture pattern

1. Give every agent and user a verifiable identity

Use your identity provider to issue short-lived tokens to users and workloads. Give each production agent its own identity, owner, environment and lifecycle. Avoid one API key shared by several agents or business units. Google Cloud’s 21 August identity update makes the same broader point: static credentials and legacy IAM policies do not match machine-speed agent execution, and agent, human and workload identity need to converge around verifiable standards.

2. Carry user context, not user secrets

The agent should receive validated claims rather than a reusable password or long-lived API token. When it calls another service, use temporary user-scoped credentials or an on-behalf-of token exchange. This lets the downstream system apply its own access rules while the agent avoids storing per-user secrets.

In the AWS example, department claims become session tags for attribute-based access control, while external Salesforce access uses an on-behalf-of exchange. The same pattern can work with any combination of cloud IAM, OAuth 2.0 and enterprise SaaS that supports scoped tokens.

3. Authorize the tool call and its parameters

Allowing an agent to use a “refund” tool is not the same as allowing every refund. The policy should evaluate the principal, action, resource and relevant inputs: amount, customer segment, destination account, data classification or time window.

The current AgentCore authorization documentation shows this explicitly: OAuth claims and MCP tool-call arguments are combined into a policy request. That allows a rule such as “finance managers may approve refunds below a threshold” to be enforced before the tool executes.

4. Default to deny

A policy engine should deny actions unless a rule explicitly permits them. AWS’s Cedar policy guidance also uses a forbid-overrides-permit model, so a hard restriction cannot be accidentally weakened by a broader allow rule. The language or product may differ, but the design goal is the same: an unknown action, tool or context should fail closed.

5. Bind authorization to the full action chain

Agents often complete a task through several individually harmless calls that become risky in sequence: search a customer, export data, create a file, then send it externally. Per-call authorization is necessary but not always sufficient. High-impact workflows need session-aware limits, step-up approval and checks on cumulative behavior.

What should stay outside the model

Do not ask the model to decide whether a user is a finance manager, whether a record is confidential or whether a payment is below an approval threshold. Models can interpret intent and choose candidate tools. Identity verification, permission evaluation and irreversible controls belong in deterministic services that can be tested and audited.

Prompt instructions still matter, but they improve behavior rather than establish authority. If the prompt says “never reveal payroll data” while the retrieval layer allows every employee to query the payroll index, the system is relying on politeness where it needs enforcement.

A practical rollout for founders and technical teams

• Inventory agents and owners: record every agent, environment, business owner, tools, data stores and credential type.
• Remove shared permanent credentials: replace them with short-lived, workload-specific and user-bound access where possible.
• Map every high-impact tool: document who may call it, with which parameters, and which actions require human approval.
• Move enforcement downstream: apply database, API, SaaS and cloud IAM controls even if the agent already filters results.
• Log the authorization chain: capture the initiating user, agent identity, tool, decision, policy version and outcome without automatically copying sensitive content.
• Test bypass scenarios: simulate prompt injection, token theft, stale roles, cross-department requests and multi-step exfiltration.

The Qomra Tech view

Agent identity is not a specialist feature to add after deployment. It is part of the product architecture. Teams should be able to answer five questions for every important action: who asked, which agent acted, under whose authority, what policy allowed it, and where the evidence is stored.

For organizations in the UAE and wider Gulf, this discipline supports faster delivery as much as stronger security. A clearly bounded agent is easier to approve, monitor, recover and expand into new workflows. Start with one production use case this week: replace its broad shared credential, propagate the user context end to end, and make the final system—not the model—say yes or no.