An AI agent that can read cloud files, query production data, update a CRM, open pull requests, or send messages is no longer just a model call. It is a workload with authority.
That means one of the most important production decisions has nothing to do with prompts or model benchmarks:
What identity does the agent use when it acts?
A surprisingly fragile answer is still common: put a long-lived API key in an environment variable, let several agent jobs share it, and rely on the model to behave.
A safer architecture is almost the opposite: give the agent or workflow a distinct identity, mint short-lived credentials for the specific task, grant only the permissions it needs, and require a stronger boundary before consequential actions.
The cloud platforms are increasingly moving in this direction. Google Cloud now explicitly documents agent identities and promotes unique, short-lived identities for agents; AWS has long recommended temporary credentials for machine identities and workloads. OpenAI's prompt-injection guidance separately recommends limiting an agent's access to only the data needed for its task and reviewing consequential actions before confirmation.
Feature check — September 4, 2026: Google Cloud's current IAM documentation describes SPIFFE-based agent identities tied to an agent's lifecycle, while its Workload Identity Federation documentation supports keyless access with short-lived credentials for external workloads. AWS currently recommends IAM roles and temporary credentials for workloads wherever possible. Product details and availability can change, so verify the provider-specific mechanism before implementing it.
The core mistake: treating an agent like a developer laptop
Imagine a support agent with four tools:
- search customer records;
- read billing information;
- create refunds;
- send an email.
The easiest implementation is one service account with permission to do all four things, plus one permanent credential stored in the agent service.
Now every run has the authority of the most powerful action—even when the task is only “summarize this customer's last two tickets.”
That creates three avoidable problems.
1. The credential lives longer than the task
A support-summary task might last 20 seconds. A permanent API key can remain valid for months or years until somebody rotates or revokes it.
If the credential leaks through logs, debugging output, a compromised dependency, a developer machine, a container image, or another route, the attack window is disconnected from the lifetime of the task that needed it.
AWS's current Well-Architected guidance makes this distinction explicitly: temporary credentials expire, while long-term credentials remain a standing risk if disclosed, shared, or stolen.
2. The permission set is broader than the task
The summarization step does not need refund permission. The refund step does not necessarily need access to every customer. A billing lookup may be read-only.
When every tool shares one broad identity, the architecture throws away those distinctions.
3. The audit trail becomes muddy
If ten agents and three background jobs all use the same credential, a log entry that says service-account-prod updated record 123 answers only part of the incident-response question.
You still need to know:
- which agent run acted;
- which user or system initiated it;
- what task it was performing;
- which policy allowed the action;
- what the model requested;
- what the executor actually performed.
Identity should make attribution easier, not force you to reconstruct it from application logs after something goes wrong.
Think in an authority envelope
A useful way to reason about agent security is to stop asking “Does this agent have access?” and instead define an authority envelope for each run.
That envelope has five dimensions:
| Dimension | Question |
|---|---|
| Identity | Which agent, workflow, service, or user is acting? |
| Scope | Which resources and operations can it access? |
| Lifetime | How long are those permissions usable? |
| Context | For which tenant, task, user, environment, or destination are they valid? |
| Consequence boundary | Which actions require an additional policy check or human approval? |
A strong design narrows all five.
This gives a more practical security heuristic than “store the key in a secret manager.” Secret storage matters, but a perfectly stored permanent key with excessive privileges is still excessively powerful.
Pattern 1: give the agent a workload identity
Cloud applications already have a mature answer to “How should software authenticate?”: workload identity.
On AWS, workloads running on services such as EC2 or Lambda can receive temporary IAM-role credentials instead of embedding long-lived access keys. AWS also documents temporary-credential approaches for external workloads.
On Google Cloud, Workload Identity Federation lets external workloads exchange an existing trusted identity for federated access rather than storing a service-account key. Google recommends federation rather than service-account keys where possible.
Google has now pushed the concept further for generative AI with Agent Identity. Its current IAM documentation describes agent identities as SPIFFE-based identities tied to an agent's lifecycle and mapped to the resource where the agent is hosted.
The implementation details differ by platform, but the architectural idea is portable:
agent runtime
↓ proves workload identity
identity / token service
↓ returns short-lived credential
policy-scoped API or tool
The agent does not need to know a permanent secret. It needs a way to prove what workload it is so a trusted identity layer can issue the right temporary authority.
Pattern 2: separate the agent's identity from the user's identity
There are two very different cases that often get mixed together.
The agent is acting as a service
Example:
Every night, classify newly arrived support tickets and add an internal category tag.
This is a background workload. It should normally act as its own service/agent identity with exactly the permissions required for that workflow.
The agent is acting on behalf of a user
Example:
Draft a reply from my mailbox, then send it after I approve.
Here the user's authority matters. The system may need delegated OAuth access or another provider-supported on-behalf-of flow.
The wrong shortcut is to copy a user's long-lived token, browser cookie, or broad personal credential into a generic agent environment and treat it as the agent's identity.
Google's current IAM product guidance explicitly highlights orchestrating OAuth flows so agents can act for users without exposing user credentials. The key principle is broader than Google Cloud: delegation should be explicit and scoped; impersonation should not be an accidental side effect of having someone's secret.
A useful mental model is:
Who is doing the work? → agent/workload identity
Whose authority is involved? → optional user delegation
What can this run do? → scoped policy / token
Those can be represented separately even when the final API call needs both pieces of context.
Pattern 3: split read, draft, write, and admin authority
Not every tool call deserves the same privilege.
A practical agent tool catalog can classify actions like this:
| Class | Examples | Default boundary |
|---|---|---|
| Read | fetch ticket, list files, query documentation | narrow read-only token |
| Draft | prepare email, generate SQL proposal, compose refund request | no external side effect |
| Write | update CRM, send message, create issue | explicit write scope; policy check |
| High consequence | refund money, delete data, change permissions, deploy production | stronger approval / separate role |
| Admin | manage identities, secrets, organization policy | generally outside ordinary agent authority |
This design does something important: it prevents a model that only needs to consider an action from automatically possessing the credential required to perform it.
An email agent can draft with no send permission. A deployment agent can inspect a failed release without holding a production-deploy credential. A finance-support agent can calculate a suggested refund without being able to issue it.
Only at the action boundary does the executor request the stronger capability.
Pattern 4: mint credentials just in time
A long-lived key is often created because the application needs an easy way to authenticate repeatedly.
A brokered design flips the flow:
1. Agent receives task
2. Agent proposes/requests tool action
3. Policy layer checks task + identity + resource + action
4. Credential broker mints or obtains a short-lived token
5. Executor performs the permitted action
6. Token expires
The model never needs access to the underlying cloud key or refresh secret.
This is particularly useful when the agent can read untrusted content. A malicious instruction hidden inside a document or webpage may influence the model, but it still has to pass through an external authorization layer before receiving a capability it did not already have.
That is why identity architecture and prompt-injection defense belong in the same conversation.
OpenAI's current prompt-injection guidance recommends limiting agent access to only the data needed for a task and carefully reviewing consequential actions. Model-level defenses matter, but access control outside the model limits the damage when interpretation fails.
The executor, not the model, should enforce permissions
An agent prompt can say:
Never delete customer data.
That is useful behavioral guidance. It is not an authorization system.
If the tool token still allows DELETE /customers/*, then the technical capability exists regardless of what the prompt says.
A production executor should be able to reject a tool call because of deterministic policy, for example:
agent: support-triage
requested action: delete_customer
policy result: DENY
reason: action not present in support-triage role
Or:
agent: billing-assistant
requested action: refund £240
policy result: REQUIRE_APPROVAL
reason: refund exceeds autonomous-action threshold
The exact rules depend on the product, but the architecture should make “the model asked for it” insufficient authorization.
Give each run enough identity to answer “who did this?”
A unique identity does not necessarily mean creating a permanent cloud service account for every individual prompt.
You can combine a stable workload identity with short-lived run context.
For example, record:
workload: support-agent-prod
run_id: run_01...
initiator: user_4821
workspace: tenant_77
task: summarize_and_draft_reply
tool: gmail.send
policy_decision: approved_by_user
token_session: session_...
The cloud audit log may identify the workload principal. Your application log can join that identity to the agent run, tenant, user delegation, policy decision, and model/tool trace.
The goal is not maximum logging. The goal is reconstructable authority: after an incident, you should be able to tell why an action was possible and which boundary approved it.
Be careful not to dump secrets, raw authentication headers, or unnecessarily sensitive user content into those logs while doing so.
A small-team architecture that does not require an IAM platform project
This can sound like enterprise security theater if you are a three-person startup. It does not have to be.
A small SaaS can improve dramatically with a modest structure.
Step 1: inventory agent credentials
List every credential your agents can currently reach:
- database URL;
- GitHub token;
- cloud key;
- Gmail/Google OAuth token;
- Slack token;
- payment-provider key;
- internal admin API token.
For each one, write down what can this credential do if fully abused?
That is the real starting risk, not how securely .env is stored.
Step 2: remove credentials the task does not need
If a research agent never sends email, do not mount the email credential into its runtime.
If a coding-review agent only reads a repository, give it read access rather than the same token the deployment bot uses.
If the infrastructure supports separate containers, workers, tool servers, or processes, use those boundaries to avoid making every secret available to one universal agent process.
Step 3: replace permanent cloud keys with workload identity where practical
Use the provider's native mechanism:
- IAM roles / temporary credentials on AWS;
- attached service accounts, Workload Identity Federation, short-lived service-account credentials, or Agent Identity where appropriate on Google Cloud;
- the equivalent workload/managed-identity mechanism on the platform you actually run.
The exact brand matters less than the property: the workload authenticates without carrying a permanent reusable secret.
Step 4: create separate read and write roles
You do not need fifty policies.
Even a split such as support_agent_read and support_agent_write is better than one omnipotent agent_prod credential.
Mint the write authority only when the workflow reaches a write step.
Step 5: add one policy gateway before consequential tools
Put refunds, deletes, sends, publishes, deployments, permission changes, and external sharing behind an executor-level check.
The check can be simple at first:
- is this action allowed for the agent role?
- is the resource inside the current tenant?
- is user delegation present if required?
- is confirmation required?
- has the approval expired?
The important part is that the decision happens outside the model.
Step 6: join identity to the audit trail
Log the agent/workload principal, run ID, initiator, requested action, policy result, and target resource identifier.
Now a suspicious action can be traced without guessing which of six systems happened to possess the shared token.
Five anti-patterns worth removing first
One production API key shared by every agent
This maximizes blast radius and minimizes attribution.
A human administrator token reused by automation
The automation inherits privileges that were granted for a person's interactive work, often including capabilities the agent never needs.
Permanent credentials baked into prompts or tool definitions
The model should not need to see raw secrets to call a properly designed tool.
“Read-only” enforced only by prompt instruction
Read-only should exist in the permission policy or API surface, not merely in natural-language guidance.
Confirmation after the agent already received the powerful token
If possible, mint or expose the stronger capability after approval, not before. That makes approval a real authority boundary rather than a UI ritual.
What short-lived identity does not solve
Identity is not a magic agent-safety layer.
A correctly authenticated agent can still make a bad decision within its allowed scope. A one-minute token with permission to delete the exact wrong record can still delete that record. A user can approve a misleading action. A compromised executor can bypass model-level safeguards.
You still need:
- input and prompt-injection defenses;
- tool validation;
- tenant/resource isolation;
- confirmation for high-impact actions;
- rate and spend limits where appropriate;
- monitoring and anomaly detection;
- recovery and revocation paths;
- normal software security around the agent runtime.
Short-lived, scoped identity does something narrower and extremely valuable: it reduces how much standing authority exists and makes that authority easier to attribute and revoke.
A useful design test
For every production agent, ask this question:
If an attacker could fully control the model's next tool request, what could they accomplish with the credentials already available to this run?
If the answer is “anything our backend can do,” the model is not the main problem. The authority boundary is.
A healthier answer sounds like:
It can read these three resources for this tenant for the next few minutes. It can draft a write, but the executor will not obtain write authority until the policy check passes. Admin operations are not available to this workload at all.
That does not guarantee safety. It gives failure a much smaller shape.
Conclusion
The more capable AI agents become, the less sensible it is to authenticate them with one shared permanent secret.
Treat the agent as a workload. Give it an identifiable principal. Use temporary credentials where the platform supports them. Separate service identity from user delegation. Split read authority from consequential write authority. Put deterministic policy and approval outside the model. Record enough context to reconstruct who acted and why.
The useful security question is no longer just “Can the agent call this tool?”
It is:
“Which identity is calling it, with whose authority, for how long, against which resource, and what happens before the action becomes irreversible?”
That is the layer that turns an impressive agent demo into a system you can responsibly operate.
Sources
Checked September 4, 2026: