Security framework for managing AI coding agents

Defining agent identity

When deploying AI agents, security teams must decide how these entities should be identified within a system. Vinay Thakker, CTO of KloudStax, argues that an agent should never simply borrow a human's login because it would inherit every permission that person possesses. Instead, the agent should have its own identity, with the human's identity attached only when the agent acts on their behalf.

The specific identity structure depends on whether the agent is performing a business job or a personal task. An agent triaging support tickets for a company should run as its own identity with permissions scoped strictly to that job. For an agent performing a task for an engineer, it should carry the engineer's identity alongside its own so that logs show both actors.

This dual-identity approach ensures that the agent can only perform actions that both the agent and the human are authorized to do. By keeping these identities distinct, organizations can maintain a clear audit trail of who initiated a request and what the agent actually did. This prevents the 'confused deputy' problem where an agent might be tricked into using a user's permissions in unintended ways.

Hardening credentials

Managing secrets for AI agents requires a combination of short-lived credentials and secure proxies. Thakker warns against handing agents long-lived secrets, as a leak would remain useful for a long time. The strongest security setup involves a proxy that verifies the agent's identity and obtains a short-lived credential scoped to a single call.

If an agent must hold a token directly, it should be tied to the specific machine or container that requested it. This ensures that if a token is stolen, it is useless in any other environment. Furthermore, security teams must ensure that refresh tokens are not stored in the same environment as the agent's active tokens, as these are essentially long-lived secrets.

For services that only accept static API keys, a proxy is the only way to keep the key out of the agent's reach entirely. A proxy that simply forwards a caller's token downstream is dangerous because it turns every hop into a potential theft point. Instead, the proxy should concentrate the agent's authority while enforcing least privilege and a destination allowlist.

The 10-line command policy

For teams starting with AI coding agents, Thakker suggests a 10-line command policy based on an allowlist rather than a list of forbidden actions. Because coding agents are designed to find ways around restrictions, a hard deny list is usually insufficient. Every line of this policy should be enforced by a technical harness rather than by asking the AI model to behave correctly.

The policy should specify that the agent works inside one checked-out repository in a disposable environment. It should only be allowed to run approved commands such as build, test, lint, and format tools, along with read-only git access. Anything outside of these specific tools should require human intervention or be blocked entirely by the system.

Additional rules should prevent the agent from reading secret files like .env files or SSH keys, even if they appear in the workspace. Network access should be off by default, except for internal package mirrors and specific project hosts. Finally, the policy must ensure the agent cannot escalate its own privileges, change its own configuration, or push to protected branches without a human review.

Network and data safety

Preventing data exfiltration requires a 'deny by default' approach to network access. Thakker suggests testing whether an agent combines private data, content from untrusted sources, and a way to send data out. If an agent has all three capabilities, a single poisoned email or ticket could be enough to move company data to an attacker.

To mitigate this, agents that read customer emails should have no outbound network path at all. When network access is necessary, the system should list exact hosts rather than using wildcards. This prevents the agent from reaching out to arbitrary locations that an attacker might control.

Package installs are a common way for allowlists to fail because public registries often end up on the approved list. Using an internal artifact repository closes this gap by giving the company one place to hold back unreviewed packages. For URL parameters, Thakker notes that network rules cannot stop data from being included in a query string, so the design must ensure the agent cannot send data without approval after reading untrusted content.

Testing and recovery

Security teams should use red teams to test the system surrounding the model rather than the model itself. The goal is to assume an injection will eventually work and then measure how far a hijacked agent can travel. Automated tests should run every time a new tool or connector is added to check for known paths like reading credentials or reaching unauthorized hosts.

Tabletop exercises should focus on quiet incidents rather than loud ones. A hijacked agent is designed to stay quiet by reading the data it is already allowed to access and calling the systems it is permitted to use. Rehearsing a loud incident, like a massive cloud bill, teaches the wrong instincts for detecting a sophisticated attacker who is slowly leaking data over time.

Recovery from an agent incident is complex because the attacker may have written instructions into the agent's memory or shared configuration files. If an attacker successfully modifies a reply template or a shared file, the next session will pick up those instructions and start the attack again. Therefore, recovery means cleaning everything the agent could write to, not just revoking its temporary credentials.

Implementation steps

Organizations should begin by establishing a secure environment for their agents. This includes setting up a disposable workspace where the agent is isolated from the rest of the corporate network. This isolation ensures that even if the agent is compromised, the blast radius is limited to a single repository.

Next, teams should implement a proxy system for credential management. This proxy should handle the injection of short-lived tokens for every request the agent makes. By ensuring the agent never sees the actual secret, the organization significantly reduces the risk of credential theft during a session.

Finally, companies should adopt an internal artifact repository for all software dependencies. By pointing agents at an internal mirror instead of public registries, the security team can vet every package before it is made available to the AI. This creates a controlled gate for all external code that the agent might attempt to download or execute during its tasks.

Policy summary

The first ten lines of a command policy for an AI coding agent should include the following requirements: 1. Work inside one checked-out repository in a disposable environment. 2. Run only approved commands like build, test, lint, and format tools. 3. No credentials live in its environment; use a broker. 4. Cannot open files with secrets like .env or SSH keys. 5. Network access is off except for internal mirrors and specific hosts. 6. Packages come only from the internal artifact repository. 7. Can commit to its own branch but cannot push to protected branches. 8. Changes to shared infrastructure or data stop and ask. 9. Cannot escalate privileges or change its own policy. 10. Every command is logged with the agent’s identity and the task that triggered it, with a runtime cap to end the session.

These rules are not new; they are the same disciplines applied to CI pipelines, now applied to a system that writes its own commands. By enforcing these limits at the harness level, organizations can leverage the power of AI coding agents while maintaining a robust security posture. This approach ensures that the agent remains a tool for the business rather than a liability for the network.

Red team tactics

Red teams should be tasked with finding paths that have not been written into automated tests. While automated tests check for known vulnerabilities like reaching an off-list host, human red teams can hunt for creative ways to abuse the agent's tools. They should look for ways to move data out of the company using the agent's legitimate permissions.

A good tabletop exercise involves revealing clues one at a time to the security team. Start with a customer complaint, then an odd pattern in the logs, and finally the poisoned ticket itself. This forces the team to decide who makes the call to shut down the agent and how to do so without taking down the entire support service. The goal is to practice identifying and stopping a hijacked agent before it can cause significant damage.

The most critical question for any response team is how to ensure the agent is truly gone after a session is ended. If an attacker has successfully injected instructions into a shared configuration file, the agent will simply resume its malicious behavior in the next session. Security teams must be prepared to audit and clean every resource the agent had the permission to write to during its active window.

Data exfiltration risks

Data exfiltration is a primary concern when agents are given access to internal records and the open web. If an agent can read private data and has an outbound network path, it can be used to move information to an attacker. For example, a support agent reading customer emails should not have an open outbound path at all, as its replies should be routed through a controlled channel.

Network rules should be enforced in a way that the agent cannot edit. This prevents a hijacked agent from opening new ports or reaching out to new IP addresses. By listing exact hosts rather than using wildcards, the organization limits the agent's reach to only the specific services it needs to function correctly.

The challenge of URL parameters remains a significant hurdle because a plain GET request to an approved host can still carry data in the query string. Because of this, the best defense is design: once an agent has read untrusted content, it should not be able to take a consequential action or send data out without a human approving the specific request. This ensures that even if an agent is tricked, it cannot act on its own without oversight.

Infrastructure changes

When agents are used to manage infrastructure, the permissions must be split between proposing a change and applying it. An agent might be allowed to run a plan or open a change request, but the actual application of that change should go through the same review pipeline as a human's change. This ensures that no single agent can unilaterally modify the production environment without a human-in-the-loop check.

The distinction between a business job and a personal task is key here. A ticket-triage agent is a business job and should have read access to the queue and write access only to labels. An infrastructure agent is usually doing a task for an engineer, so it should carry that engineer's identity alongside its own to ensure accountability for the specific changes made.

By following these identity and permission rules, organizations can prevent agents from becoming 'confused deputies.' A confused deputy is an agent that is tricked into using its authority to perform actions that the user did not intend. Strict scoping of permissions ensures that the agent only does what it was specifically designed to do, protecting the organization from both accidental errors and intentional attacks.

Summary of controls

The security of AI coding agents relies on a multi-layered approach that combines identity, network, and command-level controls. It is not enough to simply trust the model to behave; the system must be designed to prevent the model from doing anything it shouldn't. This involves using proxies to hide secrets, internal repositories to control dependencies, and allowlists to restrict commands.

These controls are essentially the same ones used for CI/CD pipelines, but they are more critical here because the agent is generating its own commands dynamically. By applying these standards, companies can safely integrate AI into their development workflows. This framework provides a clear path for moving from experimental AI use to secure, production-ready deployments.

Ultimately, the goal is to ensure that every action an agent takes is logged, scoped, and reversible. By maintaining a clear audit trail of both the agent and the human who triggered it, organizations can maintain visibility into what is happening. This allows for rapid response to incidents and ensures that the AI remains a productive tool rather than a security risk.

Why it matters

For the curious reader, this story highlights that AI security is not just about the model's behavior, but about the environment it lives in. As you see more AI tools integrated into coding and business workflows, understanding these 'guardrails' becomes essential for anyone overseeing these systems. It moves the conversation from 'will the AI do something bad?' to 'how do we build a system where it physically cannot do something bad?'

This shift toward 'hard' enforcement—where the system blocks a command regardless of what the AI wants to do—is the standard for enterprise security. It protects against both the 'hallucinations' of the AI and the deliberate injections by malicious actors. By following these principles, organizations can adopt AI more quickly while minimizing the risk of massive cloud bills or data breaches.

The framework also emphasizes the importance of human oversight in high-stakes actions. Whether it is a deployment, a deletion, or a migration, the human remains the final authority. This ensures that while the AI can do the heavy lifting of writing code and running tests, the ultimate responsibility for the infrastructure remains with the people who understand the business context.

Key takeaways

The most important takeaway is the move toward identity-based security for agents. Instead of giving an agent a 'blank check' to act as a user, give it its own identity and only let it act on behalf of a user when necessary. This creates a clear paper trail and limits the damage an agent can do if it is hijacked or behaves unexpectedly.

Another key point is the use of proxies and short-lived credentials. If an agent never sees a secret, it cannot leak it. This is a fundamental security principle that is often overlooked in the rush to deploy AI. By ensuring that credentials are only injected at the moment of use, you eliminate a massive surface area for potential attacks.

Finally, the 10-line policy serves as a practical starting point for any team. It focuses on the most common ways agents can cause harm: accessing secrets, reaching the open internet, and making unauthorized changes to the codebase. Implementing these ten rules provides a solid foundation that can be expanded as the agent's capabilities and the organization's needs grow over time.

Next steps for security

Security teams should start by auditing their current AI deployments to see if agents have broad network access or long-lived secrets. If they do, they should prioritize moving to a proxy-based credential system. This is one of the fastest ways to reduce the risk of a hijacked agent leaking sensitive information.

Teams should also begin drafting their own command policies based on the 10-line framework. They should start with a strict allowlist for the most common tools used by their developers. This will help establish a baseline of 'normal' behavior for the agents and make it easier to spot anomalies during red team testing.

Finally, organizations should consider setting up internal artifact repositories if they haven't already. This gives them a single point of control for all the code and packages their AI agents use. It is a critical step in ensuring that the agents are only interacting with trusted, reviewed software, which is a cornerstone of a secure AI strategy.

Conclusion

As AI agents become more common in software development, the security of these systems will become a major focus for IT and security professionals. The framework provided by KloudStax's CTO offers a practical, fact-based approach to managing these risks. It moves away from the hype of AI capabilities and focuses on the reality of securing a system that writes its own commands.

By focusing on identity, least privilege, and hard technical limits, companies can deploy AI agents with confidence. These measures ensure that the agents are helpful tools that increase productivity without creating new vulnerabilities. It is a matter of applying existing security disciplines to a new and powerful technology.

The ultimate goal is to create a system where the AI can work autonomously within a safe 'sandbox.' This sandbox is defined by the command policy, the network limits, and the identity controls. When these three elements work together, organizations can fully realize the benefits of AI coding agents while keeping their data and infrastructure safe from unauthorized access or accidental damage.

Agent security summary

To summarize, the security of AI coding agents is built on three pillars: identity, isolation, and enforcement. Identity ensures we know who is doing what; isolation ensures the agent can only see what it needs to see; and enforcement ensures the agent can only do what it is allowed to do. These are the core