The agent that can do anything
The prototype was exciting. The agent reads a customer email, looks up the order in your database, checks the payment in Stripe, updates the CRM and drafts a reply. To get it working, a developer gave it an admin API key for each service and the production database password, all in a .env file. Some of those keys may even be in the system prompt, so the agent knows how to call things.
Now it is heading towards production, and somebody asks the obvious question: if the agent can do all that, what stops it from doing something else?
Why agents end up over-privileged
- It is quickest to reuse existing admin keys during a prototype, and they never get replaced.
- Agent frameworks make it easy to pass credentials around as plain strings.
- Tools are defined broadly (run any SQL query, call any endpoint) instead of narrowly (look up an order by number).
- Secrets end up in prompts, logs or traces where the model or a support engineer can see them.
- Nobody treats the agent as a separate identity with its own permissions.
The difference from ordinary software is that an agent's behaviour is driven partly by text it reads. A cleverly written customer email or a web page can try to steer it. If the agent holds broad credentials, a successful injection can use them.
What is at risk
| Weak point | What can happen |
|---|---|
| Admin keys given to the agent | A manipulated agent can change or delete far more than its job needs |
| Secrets in prompts | The model can be tricked into repeating them in a reply |
| Secrets in logs and traces | Anyone with log access, or a logging vendor, can read them |
| Long-lived keys | A leaked key keeps working until someone notices |
| Shared credentials | You cannot tell the agent's actions from a person's |
How we manage agent secrets
- Give the agent its own identity. It gets separate service accounts or API keys in each system, never a person's login or a shared admin key.
- Narrow the tools. Each tool does one specific thing (fetch order by number, add CRM note), and its credential only allows that. Database access is read-only or limited to specific tables or stored procedures where possible.
- Keep secrets out of the model. Credentials are held by the tool code, not placed in prompts, so the model never sees them and cannot repeat them.
- Store them in a secrets manager such as AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, loaded at runtime rather than committed in files.
- Use short-lived credentials where the platform supports them, such as cloud role-based access or OAuth tokens that expire, and rotate the rest on a schedule.
- Redact secrets from logs and traces automatically, including in LLM observability tools.
- Require a person's approval for high-impact actions like refunds, deletions or outbound messages above a threshold, and log every tool call with its inputs and outcome.
If the agent uses MCP servers or third-party tools, we apply the same rules to them: what they can access, where their credentials live and what they log.
After the rework
The agent can do its job and not much more. If someone manages to manipulate it, the damage is limited to what its narrow tools allow, and the risky actions still need a person. Secrets live in a vault rather than in files, prompts or logs. And every action the agent takes is recorded under its own identity, so you can see exactly what it did.
Is your agent set up like this?
- Your agent uses admin or personal API keys.
- Credentials are stored in .env files, config or code.
- Keys or passwords appear anywhere in prompts, logs or traces.
- The agent can run arbitrary queries or call any endpoint.
- You could not easily list everything the agent is able to change.