Autonomous Tools Require Just-In-Time Credential Leasing

Stop passing static environment variables to agent sandboxes. If an LLM-driven agent goes off the rails or gets hijacked by a prompt injection, a permanent API key hands the attacker everything that key can touch, for as long as nobody notices.

The Anatomy of an Agentic Blast Radius

The standard setup is easy to describe. An orchestration framework starts a worker. The worker reads a .env file or a config block. That file holds administrative keys for a long list of SaaS tools: ticketing, CRM, cloud, source control, messaging. Every key is permanent, and every key is loaded whether or not the current task needs it.

We used to run microservices this way, and it was tolerable. A classical service has a fixed code path. You can read it, test it, and reason about which calls it will make, so the key’s scope roughly matches the code’s behaviour.

An agent breaks that assumption. It decides at runtime which tools to call, in what order, and with what arguments. It also processes untrusted natural language: a customer email, a scraped web page, a PDF from a vendor. Any of those can carry instructions. Current models cannot reliably tell data from commands, and careful prompt wording reduces the risk without removing it.

So define the blast radius as the set of credentials the agent can read, weighted by how long they stay valid. With static keys, the lifetime is unbounded. A successful prompt injection then does far more than leak a system prompt. It can pull customer records out through an injected Zendesk key, or provision unauthorised infrastructure with static AWS credentials. And because the key is permanent, the attacker keeps access after the session ends.

None of this is exotic. It is an ordinary secret-management mistake, made on a component that strangers can now steer.

Architecting the Just-in-Time Credential Broker

Throw out the microservice mental model. An agent is a probabilistic actor, not a deterministic script. You cannot audit its code path in advance, which means you cannot size its permissions in advance either. The guardrail belongs at the execution layer, where credentials are issued, not in the prompt.

Our position: a dedicated credential broker, such as HashiCorp Vault, should be the default for any multi-agent system that touches more than one external service. The agent never holds a standing secret. At most, it holds a short-lived lease.

We build to a five-step flow:

1. The agent produces a plan. The plan is structured and multi-step, and it names the tools each step needs.
2. The platform validates the plan. A policy layer checks the requested tools against what this agent role and task type may use. The agent doesn’t get to ask for whatever it likes.
3. The platform requests scoped credentials from Vault. One request per step, not per session. The scope matches the step: read-only on one resource, say, rather than an admin token on the whole tool.
4. The agent uses the credential for the call. The platform injects it at the tool boundary. It never enters the prompt, the context window, or the sandbox’s environment.
5. The lease is revoked. When the call returns, the platform revokes the lease. The TTL is the backstop, not the plan.

Step 2 matters more than it looks. The agent proposes and the platform disposes. Say a hijacked agent slips “export all customer tickets” into its plan. The validation layer rejects the tool request before Vault is ever asked. Vault then enforces a second line of defence: even an approved request yields only the narrow scope that step needs.

One caveat on step 5. Revocation is only as strong as the backend. Vault can revoke many dynamic secrets immediately, but AWS STS credentials cannot be individually invalidated once issued. For those, the short TTL does the real work.

This is least privilege applied per step. The agent requests access, uses it, and discards it, all within the span of one step.

15-Minute TTLs: The Statutory Board Procurement Crew

Last quarter we built a multi-agent procurement crew for a Singapore statutory board. It handles supplier research, quotation comparison, and the drafting of procurement documents. Several agents, several systems, and some of those systems reach into the client’s AWS environment.

The compliance constraint was not negotiable. The client’s security baseline prohibited long-lived credentials for elevated automated processes. A long-lived key in an agent’s config was a non-starter before we wrote a line of code. We treated that as a design requirement, not an obstacle.

We integrated the agent platform with Vault and used its AWS secrets engine to issue Amazon Security Token Service (STS) credentials. Each one carried a hard 15-minute Time-To-Live, with no renewal path for the agent. If a task needed more time, the platform went back through plan validation and asked for a fresh lease.

We chose 15 minutes as the shortest practical lease for this integration. The reasoning is simple. Agents loop. A model that hits an ambiguous document may retry the same call dozens of times, or simply wander. An agent can also be steered by content it reads mid-task, like a supplier PDF with instructions buried in it. In both cases, the credentials in play expire on a clock the agent does not control. Horizontal privilege escalation, where a compromised step reaches for adjacent systems, needs time and a standing foothold. A 15-minute lease scoped to one step offers very little of either.

There is a trade-off. Short leases mean more issuance calls and more plan re-validation on long tasks. That adds latency, and it adds one more dependency that has to stay up. We accepted the cost.

We also can’t prove that nobody attempted an injection against this crew. What we can say is that the design bounds the worst case: a stolen credential is narrow in scope and dead within a quarter of an hour.

Zero-Trust Infrastructure: wGrow’s Internal Deployment Agent

We applied the same rule to ourselves. wGrow runs an internal deployment agent that evaluates infrastructure code and provisions AWS resources. It is the riskiest thing we let an agent do, because the credential it needs is exactly the one an attacker wants.

The old pattern for automation servers is a long-lived IAM user with access keys stored on the box. We rejected it. Those keys outlive the job, outlive the engineer who created them, and get copied into places nobody tracks.

Instead we moved to OpenID Connect (OIDC) federation. The agent sandbox presents an identity token, and AWS lets it assume a transient role in exchange. There is no long-lived cloud secret on the box to steal. The only stealable material is the short-lived identity token and the role session it buys, each bounded by a TTL.

The sequence is granular:

• The agent evaluates the Terraform plan and works out what the change touches.
• It assumes an IAM role through OIDC, scoped to that deployment.
• It runs terraform apply.
• The moment apply finishes, the agent discards the session credentials, which expire shortly afterwards in any case.

That last step is credential disposal, not server-side revocation: the sandbox drops the temporary credentials, and the remaining exposure is bounded by the role-session TTL. We treat it as part of the pipeline, not as cleanup. No long-lived AWS access keys exist on the execution server. If someone compromises the box an hour later, they find a machine with no usable cloud credentials on it.

The cost is real. OIDC trust policies take care to write, scoping a role per deployment type is tedious, and debugging a denied assume-role call at a bad hour is nobody’s idea of fun. We pay it anyway, because the alternative is a standing key to our infrastructure, held by a component that reads untrusted input.

The Evolution of Agent Platforms into Identity Providers

Agent platforms need to become identity providers. I’d argue that’s overdue.

Most platforms today treat an agent as a stateless script with a bag of secrets. That model is wrong for a component that decides its own actions. The better model is a transient IAM identity: created for a task, granted narrow rights for a step, and destroyed when the step ends. Every credential it ever held should trace back to a specific plan, a specific validation decision, and a specific lease.

That traceability is where I expect the field to mature. Prompt engineering will keep improving, but it will remain the weakest control in the stack. A better test of a serious LLM-Ops practice is whether you can produce verifiable evidence of execution intent: this plan was proposed, this policy approved it, this Vault lease was issued for exactly these calls, and it was revoked or expired at this timestamp.

If you can’t produce that record, you don’t control your agents. You’re hoping they behave. Build the broker first, then let the agents in.