How to lock down AI agents: identity, secrets, and network rules
Most teams shipping AI agents are still treating access control as an afterthought. Vinay Thakker, CTO of KloudStax, thinks that’s backwards. In a recent interview with Help Net Security, he walked through the five decisions that actually determine whether an agent deployment is defensible: identity model, credential handling, command policy, network access, and red team testing.
Agent identity: own it or borrow it?
Thakker’s rule is simple. Neither extreme works. An agent doing a job for the business gets its own identity, scoped to that job. An agent doing a task for a specific person gets its own identity plus the requesting user’s identity attached to each call. The agent can only do what both are permitted to do, and both names appear in the logs.
Borrowing the user’s login outright is the option he rules out completely. The agent’s actions become indistinguishable from the person’s and the agent inherits everything that person can reach.
Applied concretely: a ticket-triage agent runs as itself with read access to the queue and write access only to routing and labels. An infrastructure agent carries the engineer’s identity alongside its own, but proposing a change and applying it are separate permissions. The agent can open the change and run the plan. Applying it goes through the same review pipeline a human’s change would.
Credentials: no long-lived secrets, ever
The strongest setups combine two controls: short-lived credentials that limit how long a leaked one stays useful, and a proxy that attaches the credential at call time so the agent never sees it at all. The proxy verifies the agent’s identity, obtains a short-lived credential scoped to that call, and attaches it on the way out.
Thakker flags several ways the proxy approach quietly fails:
- A proxy that attaches credentials to any request the agent makes becomes a confused deputy waiting for instructions.
- One that forwards the caller’s token downstream turns every hop into a place to steal it.
- A shared credential behind the proxy makes every agent look identical in the logs.
- A vault on the same host as the agent hasn’t protected the secret, only moved it.
He also notes that a refresh token sitting in the same environment as a short-lived token is a long-lived secret by another name.
The 10-line terminal policy for coding agents
Thakker writes agent command policy as an allowlist, not a blocklist, because a coding agent will always find the command you didn’t think to forbid. Every line is enforced by the harness, not by asking the model to behave.
- The agent works inside one checked-out repository in a disposable environment and can’t read or write anything outside it.
- It runs only approved commands: the project’s build, test, lint, and format tools, read-only git, and file edits inside the repo. Anything else asks first.
- No credentials live in its environment. Anything that needs one goes through a broker the agent can’t read.
- It can’t open files that carry secrets, such as
.envfiles, SSH keys, or cloud credential files, even if one turns up in the workspace. - Network access is off except for the internal package mirror and the specific hosts this project needs.
- Packages come only from the internal artifact repository. Adding a new dependency needs a human.
- It can commit to its own branch and open a pull request. It can’t push to protected branches, force-push, or merge.
- Anything that changes shared infrastructure or data, such as an apply, a deploy, a migration, or a delete, stops and asks.
- It can’t escalate privileges or change its own policy, hooks, or configuration.
- Every command is logged with the agent’s identity and the task that triggered it. A spend or runtime cap ends the session when hit.
Several of these controls belong in the underlying system anyway. Branch protection belongs in version control. Network rules belong in the firewall. Credential access belongs in the identity system. They should hold even if the agent finds a way around its own policy.
Network access and data exfiltration
Thakker starts every agent with no network access and works forward. The test he uses: does this agent combine private data, content from sources outside the company, and a way to send data out? With all three present, one poisoned ticket or email is enough to move data out.
When an agent does need the network, he denies by default, lists exact hosts rather than wildcards, and enforces it somewhere the agent can’t edit. Public package registries are where most allowlists quietly fall apart. Pointing agents at an internal artifact repository instead closes most of that gap.
URL parameters are the harder case. A plain GET to an approved host can carry data in its query string, and approving a host means trusting the platform, not everything someone can write on it. His preference is design over inspection: once an agent has read untrusted content, it shouldn’t be able to send data out or take a consequential action without human approval.
Red team testing for hijacked agents
Thakker’s framing here is worth repeating: test the system around the model, not the model itself. Assume an injection will eventually work, and measure what a hijacked agent can do from there. Automated tests should cover the known paths, like reading its own credentials, reaching a host off the allowlist, or editing its own configuration. Run those every time someone adds a tool or connector, because that’s when exposure changes.
For tabletop exercises, he warns against rehearsing only the loud incident. The costliest agent incident he cites involved agents spending roughly $500,000 on cloud infrastructure in about 36 hours. That one gave itself away through the bill. A hijacked agent designed to stay quiet looks like normal operation.
His preferred tabletop scenario: a support agent processes a ticket with hidden instructions, and over the following week other customers’ records leave a few at a time inside the agent’s replies to the attacker. The exercise reveals one clue at a time and asks the room what they’d do with only what they know at each stage. Can they tie the activity to one agent? Can they stop it without taking down support?
The hardest question comes at the end: after you end the session, how do you know it’s gone? If the attacker had the agent write an instruction into its memory, a shared configuration file, or a reply template, the next session picks it up and starts again. Recovery means cleaning everything the agent could write to, not just revoking its credentials.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
