By KYN AI Advisory Team — AI implementation specialists, Singapore
Every AI agent should hold its own credential, scoped to the one job it does, stored in a secrets service and rotated on a schedule you can name. Never share a key between agents, never paste one into a prompt or a config file in the code repository, and prefer short-lived credentials issued by your cloud provider's identity service over long-lived API keys. When a key leaks, scope decides the damage and rotation decides the duration.
Why do agent credentials need more care than staff passwords?
A staff member logs in, works for a day and logs out. An agent runs without anyone watching, at any hour, at a speed no person matches. A leaked agent key can be used the same way, and nobody notices until the bill or the damage arrives.
Three facts shape the rules:
- Agents act without a human session. There is no person to see an odd prompt or a login alert.
- Agents call many systems. One agent may touch the CRM, the mailbox, the model provider and the file store. Each connection is a key.
- Keys leak through ordinary routes. Code repositories, chat messages, screenshots, build logs and copied configuration files. Secret scanning tools exist because this happens often. GitHub documents secret scanning for exactly this case.
What does scope mean for an agent?
Scope is the list of things a credential can do. Narrow it on three axes.
- Resource. Which database tables, which folders, which mailbox. A reply-sorting agent reads one inbox. It does not read the finance ledger.
- Action. Read, write, delete, send. Most agents need read and a narrow write. Delete is rare. Send should wait for a person.
- Time and place. A credential valid for an hour, usable from one service, beats a key valid forever from anywhere.
A practical test: write one sentence that says what the agent does, then list the permissions. Any permission that the sentence does not require comes off.
| Agent | Needs | Does not need | |---|---|---| | Reply sorter | Read inbox, write label to CRM | Send mail, read ledger, delete | | Bill reader | Read bills folder, write draft rows to the bills table | Approve, pay, edit bank data | | Morning report writer | Read the reporting views | Any write on source tables | | Receivables chaser | Read invoices, write drafts to a review queue | Send without approval |
One credential per agent, one per environment
Share nothing across agents. If the reply sorter and the report writer use the same key, the log cannot tell them apart, and revoking one revokes both.
Keep test and production credentials apart. A test key in a developer's laptop must not open production data.
Name every credential for its agent and environment, such as reply-sorter-prod. The name should appear in every log line the credential produces.
Where should keys live?
| Option | Verdict | |---|---| | In the prompt or the agent's instructions | Never. The model can repeat it, and logs capture it. | | In the code repository | Never, even if private. | | In an environment variable set by hand | Acceptable for a short time, weak for rotation. | | In a secrets service | Standard. AWS Secrets Manager and Google Secret Manager both support access control and rotation. | | Short-lived credentials from the identity service | Preferred. No stored key to leak. |
On AWS, an IAM role attached to a service gives it temporary credentials with no key to store. Google Cloud offers the equivalent through service accounts with attached identities. Where the platform supports it, use the role and delete the key.
Third-party APIs, such as a model provider or a messaging platform, still issue static keys. Put those in the secrets service and let only the agent's role read them.
How often should you rotate?
Rotate on a schedule and on an event.
- On a schedule. Pick an interval and write it down, for example every 90 days for static third-party keys. The interval matters less than having one that is actually run. Automate it where the provider allows, because manual rotation gets skipped.
- On an event. Rotate at once when a person with access leaves, when a key appears in a log or a message, when a vendor reports a breach, or when you cannot say who holds a copy.
Rotation works only if the system can survive it. Test it: rotate the key in a staging environment and confirm the agent picks up the new one without a restart that loses work. Support two valid keys during the switch, so a run in progress does not fail.
How do you detect a leaked key?
Watch the credential's behaviour, not the key itself.
- Calls from an unknown address or region.
- Calls outside the agent's normal hours or volume.
- A read-only agent attempting a write.
- Failed authentication spikes.
- A model-provider bill that moves without a matching workload.
Set a spend cap and an alert at the model provider. Most providers let you set a usage limit per key or project; check the vendor's current settings page. A cap turns a leaked key from an open-ended loss into a capped one.
Turn on secret scanning in your code host, and scan before each commit. Both catch the common case: a key pasted into a file.
What is the revocation drill?
Practise it before you need it. A drill takes under an hour and answers four questions.
- Who can revoke, and do they have the access at 2 a.m.?
- What breaks when this credential dies? List the agents and the jobs.
- How do you issue the replacement, and where does it go?
- How do you find what the old key did? The log, filtered by credential name, should list it.
The fourth question is why every action is logged with the actor. Without it, revocation stops the damage and leaves you unable to measure it.
Which actions should still wait for a person?
A well-scoped key reduces what a fooled or hijacked agent can do. It does not remove the need for a person on high-risk actions. Outbound messages, payments, filings and deletions should wait for a named person even when the key technically allows them. See approval gates for high-risk agent actions and the agent security checklist.
Where KYN fits
KYN uses named accounts through the cloud provider's identity service, with no shared logins. Each user works through one restricted account per session, and each agent has its own restricted account. Row-level security in the database limits what any account can read. Every action is logged with the actor. The system runs in a cloud account in the client's name, so the client holds the root of trust and can revoke KYN's role without stopping the system.
The first 14 days are a review of your stack and interviews with your team, including a list of every key in use today. A full build ships in under 90 days. See security and infrastructure.
Frequently asked questions
How often should I rotate API keys?
On a schedule you will actually keep, plus immediately on any leak or staff departure. Many teams choose 90 days for static keys and use short-lived role credentials where possible, so there is nothing to rotate. Automate rotation if the provider supports it.
Can two agents share one key to save effort?
Avoid it. A shared key blurs the log and makes revocation all-or-nothing. Creating a second credential takes minutes and makes every later investigation faster.
What if the agent only reads data?
Scope it anyway. A read-only key can still expose customer records, and read access to the wrong table is a breach. Limit the tables, the rows and the time it is valid.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
