Agent Guard isolates coding agents from local AWS credentials

At a glance

What this is: This tutorial shows how Agent Guard separates a coding agent’s project workspace from AWS credentials stored elsewhere on a Mac, then lets you pass only the required values into the isolated environment.

Why it matters: It matters because local AI development can create accidental credential exposure paths, and IAM teams need predictable boundaries for secrets even when the workload is a coding agent rather than a server or human user.

Context

Coding agents can inherit far more of a developer’s local environment than the task requires, which turns a convenience workflow into a credential exposure problem. The issue is not the project itself, but the gap between what the agent needs to edit code and what it can reach on the host.

Agent Guard addresses that gap by running the agent inside an isolated microVM and exposing only the workspace you explicitly share. For identity and secrets governance, that makes local AI development behave more like a scoped execution environment than an unrestricted desktop session.

Key questions

Q: What breaks when a coding agent can read the host filesystem directly?

A: The boundary between task access and credential access breaks. A coding agent on the host can often reach project files and unrelated secrets with the same privileges, which makes accidental exposure easy. The safer pattern is to isolate the agent, share only the workspace it needs, and keep secret stores outside that mount.

Q: Why do local AI coding tools create credential risk even when the code is harmless?

A: Because the risk comes from ambient access, not from the code itself. If the agent can browse the developer’s filesystem, it may reach cloud keys, SSH material, or tokens that were never intended for the task. The right control is to separate code visibility from credential visibility at runtime.

Q: How should security teams handle secrets for coding agents?

A: Security teams should move from static secret placement to runtime delivery, using just-in-time injection, narrow scoping, and task-specific access. Coding agents should receive only the credentials they need for the current execution path, with separate handling for each environment. That approach reduces persistence, limits reuse, and makes least privilege operational instead of theoretical.

Q: What is the difference between workspace isolation and secret scoping for coding agents?

A: Workspace isolation controls which files the agent can see. Secret scoping controls which credential values the agent receives. You need both, because an isolated workspace without scoped secrets still creates overexposure, and scoped secrets without isolation still leaves the host filesystem open to inspection.

Technical breakdown

Why workspace isolation matters for coding agents

A coding agent running directly on macOS can often read any local path the user account can reach, which means project access and credential access collapse into the same trust boundary. Agent Guard narrows that boundary by moving the agent into an isolated microVM and mounting only the shared workspace. That changes the security model from broad host access to explicit path exposure. The control question is no longer whether the agent can be trusted in general, but which files and values are deliberately made visible for this task. This is a classic secrets governance problem dressed in an AI workflow. See the Secrets Management Guide.

Practical implication: Treat the agent workspace as an allowlist, not a convenience mount, and keep unrelated credential stores outside it.

How explicit environment passing limits secret exposure

Passing credentials with environment variables is materially different from exposing a credential file. A file path can reveal broader credential material, metadata, and adjacent secrets, while a single environment variable can be scoped to one value needed for one task. Agent Guard’s pass-env approach preserves that distinction by letting the agent receive only the named secret values you choose. That reduces the blast radius of local development without forcing the agent to browse the host filesystem. In NHI terms, this is about separating credential transport from credential residency, which is where many accidental exposures begin. See the API Key Management Guide.

Practical implication: Prefer value-level injection over directory-level exposure when the task only needs one or two credentials.

What changes when coding agents are treated as non-human identities

Coding agents are not human users, but they still consume credentials, touch repositories, and operate under delegated authority. That means they fit the NHI governance problem space even when they run on a developer laptop. The risk pattern is familiar: a non-human actor gets more ambient access than the task requires, then uses that access without a human pause point. The practical difference is that local machine identity now becomes part of the access path, so secrets governance has to cover not just cloud workloads and service accounts, but developer-side AI tooling as well. That is where project scoping, secret scoping, and host isolation converge. See the LLM Provider API Key Security and LLMjacking Guide.

Practical implication: Map coding agents into your NHI inventory and govern them with the same access-minimisation standards you apply to other delegated identities.

Breaches seen in the wild

• Amazon Q MCP config vulnerability 2026: A malicious .amazonq/mcp.json in a repository could make Amazon Q run commands with a developer's AWS credentials. Fixed before disclosure.
• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Local coding agents create a secrets governance problem, not just a developer convenience problem. The issue in this tutorial is that the agent can see whatever the host account can reach unless the environment is deliberately narrowed. That collapses the usual separation between code access and credential access, which is exactly where accidental NHI exposure begins. Practitioners should treat the local agent runtime as a governed access surface, not a neutral tool.

Workspace isolation is the right control boundary for developer-side AI tooling. Agent Guard’s microVM model works because it separates the project from the rest of the host filesystem, which is the real control question here. Once that boundary exists, the agent can operate on code without inheriting the developer’s broader credential estate. The practitioner implication is simple: define what the agent may see before defining what it may do.

Credential delivery should be value-specific, not environment-wide. The tutorial’s strongest operational point is that a coding agent often needs a credential value, not a credential directory. That is a governance distinction worth preserving because it keeps the task scoped to the minimum needed secret surface. For teams managing local AI workflows, the right model is deliberate injection of required values, not ambient exposure of adjacent secrets.

AI coding workflows now belong in the same governance conversation as workload identity and secrets management. When a coding agent can move between project code and host credentials, it behaves like a delegated non-human actor with access boundaries that need lifecycle control. That means inventory, scoping, and access review should extend to developer-facing AI tools, not stop at server-side workloads. The programme question is no longer whether the agent is productive, but whether its access path is bounded enough to be governable.

Named concept, credential boundary drift: this is the moment when a coding agent silently inherits more of the host environment than the task requires. The tutorial shows that this drift disappears when workspace visibility and secret delivery are separated. Practitioners should use that split as the baseline for local AI governance.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Secrets Management Guide

What this signals

Governance for local AI tooling now has to treat the developer laptop as a controlled access boundary, not just a personal workstation. If the coding agent can see the host by default, then secrets management and workspace isolation have to be designed together rather than handled as separate problems.

Credential boundary drift: this is the failure mode where an agent silently inherits more of the host environment than the task needs. The practical fix is to make path exposure and secret delivery separately governable, so the agent can work without inheriting the rest of the machine.

Coding agents already show measurable exposure behaviour in practice: Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026. That makes local isolation controls a present-day requirement, not a theoretical hardening exercise.

For practitioners

• Keep credentials outside the shared workspace Store SSH keys, cloud credentials, and local tokens in a separate location that is never mounted into the agent’s workspace. Read Guide to the Secret Sprawl Challenge.
• Pass individual secrets explicitly Use environment injection for a specific credential value when the task only needs one secret, rather than exposing a broader credential directory.
• Verify the isolated environment before expanding access Check which paths and variables the agent can already reach inside the microVM before passing any additional credentials or directories.
• Use provider-specific credential passing when appropriate Grant AWS, GCP, Azure, Vault, or Kubernetes access only when the task truly needs that provider context, and avoid opening the entire home directory. Read Guide to NHI Rotation Challenges.

Key takeaways

• Coding agents can inherit more host access than their task requires unless the runtime is isolated from the developer’s broader filesystem.
• The key control move in this scenario is separating workspace access from secret access, rather than assuming one implies the other.
• Local AI workflows should be governed as delegated non-human access paths, with explicit scoping for files, environment variables, and host reach.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Secrets Management Guide · AI Coding Agents Security Guide

Key terms

• Workspace Isolation: Workspace isolation is the separation of secrets, permissions, and operational boundaries between Databricks workspaces. It reduces cross-environment exposure, but it can also force duplication when organizations lack enterprise-wide secret governance. Without consistent lifecycle controls, isolation can become fragmentation.
• Secrets Scoping: Secrets scoping is the practice of limiting a credential, token, or key to a specific environment, pipeline, or task. It prevents a development secret from being reused in production and reduces the chance that one leaked credential can open multiple systems. In mature pipelines, scoping is a basic control for least privilege.
• Credential Boundary Drift: Credential boundary drift is the condition where a token or secret issued for one mediated workflow becomes reusable in another context. In MCP environments, it means the client can use an OAuth credential outside the protocol controls that were supposed to contain it, which weakens auditability and revocation.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.