Mark McLaughlin, Product Marketing Manager | Aurascape
November 4th, 2026

Introduction

On October 29, WIRED reported, citing anonymous sources, that an Accenture contractor gave a personal Claude Code agent administrator access to a Pentagon production system. The system reportedly held Controlled Unclassified Information on NIPRNet, the Pentagon’s unclassified network. Credentials and a network map apparently reached a website NIST had flagged as high risk. WIRED described a vulnerability at the site that could enable prompt injection and credential theft. The report does not establish that it was exploited in this incident.

Accenture says an independent investigation found the allegations without merit. The Pentagon declined comment. WIRED reported no indication that classified systems were accessed.

You don’t need to work on a Pentagon system to recognize the question this report raises: what stops an agent from misusing the access its developer already has? Consider an engineer asking an assistant to fix a bug. The engineer wants working code, and the appeal of an agent is that it can work through the steps: reading files, running commands, and calling services. The engineer may never review each step. Security has to be able to enforce limits while that work is happening.

That means making three decisions that are easy to blur together: which AI tools and accounts people can use, which company systems an agent can access, and what it can do once connected. Approving the tool and granting access gets the agent started. Controlling its actions requires understanding the interaction and stopping an unsafe step before it completes.

Start with the tool and account

A developer may try a coding extension or a command-line assistant long before it appears in IT’s software inventory. These unsanctioned tools can also arrive as desktop apps, including lesser-known services the security team hasn’t reviewed. Keeping up requires discovery that goes beyond purchased software, assesses each tool’s risk, and automatically restricts tools that violate policy.

Once the tool is approved, there’s still the account to consider. To the person using it, a personal subscription and an enterprise account may look much the same. But the rules for retention, data residency, and model training can be different. Security needs to know that company data is going through the approved enterprise tenant, under the policies the organization has agreed to.

Buying enterprise seats is a useful start, but it doesn’t ensure people use them. Entitlement enforcement checks the account, license, and model within the interaction, then applies policy. That lets a team allow private source code through the enterprise account while blocking the same transfer through a personal account. The engineer can still use the assistant, with company work kept in the right account.

Limit access to company systems

The account question leads to another important distinction. Permission to use an AI assistant is separate from permission to give it access to company systems. An enterprise AI account answers the first question; a production login opens a different door. Each needs its own approval.

Think about the engineer fixing a bug in a test environment. The agent needs the relevant code and permission to run tests. Giving it administrator access to production goes well beyond that job. Identity and privileged-access controls should keep its permissions within the task, make access temporary and revocable, and require separate approval for production changes. Those protections remain essential as teams add controls for AI activity.

Control actions before they happen

Even with those limits in place, an agent still has choices to make. Access controls establish which systems it can reach, but they don’t decide whether a particular upload, command, or tool call is appropriate for the task. An allowed connection can carry an unsafe action. To judge that action, security needs to understand the account, the requested activity, the destination, and the data involved.

The controls teams already have remain part of the answer. Network controls can restrict destinations, and endpoint tools can stop dangerous processes. AI interaction controls add the context of the coding task, so security can judge what the assistant is asking to do within an otherwise allowed connection.

NIST’s proposed initial design tenets, published October 27, offer a useful principle here: keep policy enforcement separate from the agent’s reasoning. An agent can choose how to approach a task, but instructions or untrusted content should never let it expand its own authority. The limits need to hold even when the agent chooses the wrong next step.

For that to work, enforcement has to happen where the action happens. An alert after the session ends can’t undo a leaked credential or a production change. Following the engineer’s task through three paths makes it easier to see where protection is needed.

Data sent to the model

While working on the bug, an agent might read a configuration file that contains an access key and include it in a request to the model. Reading the file and sending its contents are separate actions. An AI proxy can inspect the outgoing exchange and block the secret before it leaves. The same data could also leave through a shell command, an external tool, or a file written to a shared location, so inspecting model traffic is only one part of the job.

Commands sent to the shell

The agent may need to run a test to check its fix. When the model requests that shell command, security can inspect it in the coding conversation and block it before execution. Running the test and uploading a credentials file call for different decisions. There is also a reason to keep endpoint and runtime controls in the picture: a routine-looking test script can open a network connection that the conversation never mentions. Those controls, together with limits on outbound connections, address what happens after a command starts. Recording a command helps an investigation, but stopping an unsafe command requires enforcement before it runs.

Tool calls to other systems

If the agent calls another system, a tool gateway can check the service, the requested action, and the data being sent. Reading a ticket to understand a bug and changing a cloud resource need different permissions. That approval has to hold even if the agent tries to call the tool directly and bypass the gateway. An unapproved call should be blocked before the tool can change a system or transfer data.

Keep evidence of what happened

WIRED’s report also describes a roughly two-month delay before the agent was identified. For a security team, that raises a question: could an agent be working in your environment without you knowing? Continuous monitoring should bring that activity into view. If something goes wrong, investigators need to piece together what the person asked for, what the agent proposed, what policy allowed or blocked, and what ran.

That reconstruction takes more than a model conversation. Connecting AI interaction records with endpoint, cloud, identity, and application logs helps confirm which actions executed and which systems changed. The evidence also needs to stay beyond the agent’s ability to alter it, with access limited to the people who need it. Responders can then make containment and credential-rotation decisions from a reliable record of what happened.

Test the controls with a real workflow

A practical next step is to bring security and engineering together around a task the team already understands, such as fixing a bug. Use a safe environment and fake secrets, then follow the work through these checks before expanding the agent’s access:

• Does a new coding assistant appear in the inventory and trigger the right access policy?
• Does switching to a personal account stop work that requires an enterprise account?
• Can an agent assigned to testing reach production? Can the team revoke its access?
• Are test secrets blocked in prompts and external transfers? Are prohibited commands and tool calls stopped before execution, including attempts to bypass the gateway?
• Can investigators connect the request and policy decision to evidence of what happened?

Make time to run the approved task from start to finish, too. The engineer should be able to complete the fix. A useful test shows both that the unsafe steps stop and that the work the team intended can continue.

How Aurascape secures AI coding agents

Aurascape helps security teams put these decisions into practice while developers work. It discovers AI tools and assesses their risk, so teams can restrict unsanctioned tools as soon as they appear.

Keep work in approved accounts. Developers should be able to use the tools their organization has approved without sending company code through a personal subscription. With Coding Assistant Guardrails, Aurascape enforces approved accounts, license tiers, and models. When it detects a personal subscription, policy blocks or redirects it, keeping company code in the enterprise account.

Stop unsafe exchanges and actions. Aurascape inspects coding conversations to block sensitive data transfers, detect and block prompt injection, and stop risky commands before they reach the shell. Aurascape’s Zero-Bypass Agent Gateway prevents unapproved tool calls from executing. The MCP Gateway marks every call it approves, and the AI Proxy checks the model conversation for that mark. A direct MCP call that skips the MCP Gateway lacks the mark, so the AI Proxy blocks it before the tool runs.

Investigate with context. When a team needs to understand a session, conversation records separate what a person typed from what the coding assistant sent on its own, and show what policy allowed or blocked. Auri™, Aurascape’s natural-language governance assistant, helps investigators query that activity and examine flagged risks. They can then correlate those records with endpoint and infrastructure logs to establish what executed.

These controls work alongside identity, endpoint, and infrastructure security. Together, they give teams a way to move beyond approving an AI tool and hoping its actions stay within the task. The engineer can hand over useful work, while security enforces which account the agent uses, where it can go, and what it can do. That’s what makes delegation practical: people can let an agent help without leaving sensitive decisions to its judgment.

See how Aurascape enforces approved accounts, protects sensitive data, and stops risky actions in AI coding workflows.