How to give an AI agent its own identity, and why shared API keys break
The short answer
Give every agent its own identity, scope that identity to one job, make its credentials short-lived, log every action against the identity, and test a revocation path before you let it touch anything real. A shared API key cannot do any of those five things.
Why the shared key is the problem
Most teams start the same way. One API key in an environment variable, used by the workflow, the agent and the nightly script. It works, so nobody changes it. Then three things happen at once.
You cannot tell which agent did what, because they all act as the same user. You cannot revoke one agent without breaking the others. And when a key leaks, every system it touched is exposed, because the key never expires and holds every scope the team ever needed.
This is why the incident reports read the way they do. The agent did not break in. It was already inside, with more access than the task required.
Step 1: one identity per agent
Create a separate credential, service account or bot user for each agent, named for the job it does: invoice-chaser, lead-responder, research-briefer. Not "automation" and not the founder's login.
Write down the owner as a person, not a team. When something goes wrong at 2am, a name matters more than a channel.
Step 2: scope to the job, not to the department
List the exact actions the agent needs. For a lead responder that is: read new form rows, write a draft, send from one mailbox, append a tag. It is not "access to Gmail" and it is not "admin on the CRM".
The test is simple. If the agent were taken over by someone hostile, what could they reach? If the answer includes payroll, start again.
Step 3: make credentials short-lived
Prefer tokens that expire in hours over tokens that expire never. Where the platform supports it, generate credentials per run rather than storing one long-lived secret. Vault 2.2, announced this week, does this for agents specifically, but the same pattern exists in every cloud: workload identity, short-lived STS tokens, rotating service credentials.
If a token must live longer, rotate it on a schedule and treat rotation as part of the job, not a quarterly chore.
Step 4: log against the identity
Every action should record four fields: which agent, which tool, which input, which outcome. Not for compliance theatre. For the first hour of an incident, when the only useful question is what the agent touched and in what order.
Keep the log somewhere the agent cannot write to. An agent that can edit its own audit trail has no audit trail.
Step 5: test revocation before you need it
Kill one credential on purpose and watch what happens. If the workflow keeps running, it is using another key you forgot about. If you cannot tell what stopped, you do not have visibility.
IBM's version of this is a kill switch inside watsonx Orchestrate, plus sandboxing so one rogue agent cannot reach another. Your version can be a single flag in a database that the runner checks at the start of every loop.
The three numbers to put on the wall
Credential lifetime. The maximum time a token stays valid, in hours. If it is measured in months, that is your first project.
Scope count. How many distinct permissions one agent holds. Anything above five deserves a written reason.
Revocation time. How long it takes to fully cut an agent off, tested, not estimated.
What this costs
Nothing, for the pattern. Separate service accounts, narrower scopes, rotation and a log are available on the free tiers of the tools most teams already pay for.
Enterprise tooling like Vault or Orchestrate buys you discovery across clouds and one console. It does not buy you the discipline of scoping, which is the part that actually prevents incidents.
Questions people ask
Can I just use one strong key and rotate it often?
No. Rotation does not solve attribution. When three agents share a key, you still cannot tell which one acted.
Does this apply to no-code tools?
Partly. n8n, Make and Zapier all store credentials per connection, so you can give each workflow its own connection. That is the same idea with fewer knobs.
What is the smallest useful version?
One agent, one connection, one scope, an expiry you set, and a tested way to switch it off.
Read next: what to give an agent and what to withhold and six controls from 21 real incidents.