The Approval Prompt Is Not the Boundary

AI coding agents are teaching software teams a familiar security lesson in a new form:

The interface is not the boundary.

Over the weekend, X discussion picked up around a reported attack pattern called SymJack: a symlink-hijack technique against AI coding agents and CLIs. The specific details belong in security write-ups. The business lesson is broader and more useful for founders, CTOs, product owners, and Mittelstand teams.

When an AI coding agent asks for approval to write a file, the important question is not only what the prompt appears to say.

The important question is:

What path will the operating system actually write to, and what authority does that give the agent?

That sounds small. It is not.

Modern agents can clone repositories, inspect code, run commands, edit files, install dependencies, modify configuration, connect to MCP servers, and sometimes prepare changes that later flow into CI/CD. If a malicious or untrusted repository can make a file operation appear harmless while it resolves somewhere more sensitive, then the approval prompt has become a weak safety layer.

The issue is not that developers are careless. The issue is that AI-assisted development is crossing from “assistant in an editor” into “actor inside the delivery system.” Once that happens, filesystem semantics, repository trust, config ownership, and tool permissions become architecture decisions.

Why This Matters Now

Early AI coding felt mostly like text generation.

You asked for a function. The model suggested code. A human copied, edited, and committed it.

That workflow had problems, but the agent did not usually have much authority. It could be wrong, but it could not quietly rewrite local configuration, install a tool, or affect another project unless the human did the work.

That boundary is thinner now.

Tools like Claude Code, Cursor, Codex-style CLIs, Copilot agents, Gemini CLI, Replit agents, and related systems are designed to act inside real development environments. That is why they are useful. They can see more context, make multi-file changes, run tests, call tools, and keep working through a task.

But the more operational the agent becomes, the less useful it is to think of it as “just a prompt.”

It has an execution context.

It has filesystem access.

It may have local secrets in reach.

It may have configuration that determines which tools it can call.

It may have access to repositories that contain client code, infrastructure assumptions, deployment scripts, API integrations, test data, or internal documentation.

In that world, a path is not just a string in a dialog. It is an authority boundary.

The Approval Prompt Problem

Approval prompts are meant to create confidence.

The agent proposes an action. The human sees it. The human allows or denies it.

That model only works if the prompt accurately represents the real operation.

Symlinks make this more subtle. A path can look like it sits inside the project while the underlying write resolves somewhere else. A copied file can appear to target documentation or a harmless workspace location while the operating system follows a link to a configuration path. If the tool does not canonicalize the path before prompting, the human may approve one thing while the system does another.

This is not a new concept in software security.

Path traversal, symlink races, unsafe archive extraction, and misleading file operations have existed for a long time. What is new is the speed at which AI coding agents are being connected to developer workflows by teams that may not have treated the local development environment as a security boundary before.

That is the dangerous part.

The agent does not need to “want” anything. It only needs to be given a task, a repository, a file operation, and permission to act. If the tool’s trust model is weak, project content can influence the agent’s environment.

For a serious product team, that is not a tool preference issue. It is an operating model issue.

Local Development Is Not Low Risk

Many companies are careful around production.

They protect cloud credentials, databases, payment systems, customer data, and deployment pipelines. Then AI coding agents enter through the side door: local development.

That can feel safe because it is “only a developer machine.”

In practice, developer environments are often extremely sensitive.

They may contain:

• .env files for staging or internal services;
• SSH keys or Git credentials;
• package registry tokens;
• local database snapshots;
• customer support exports;
• cloud CLI sessions;
• browser sessions;
• MCP server configuration;
• internal tool credentials;
• access to multiple client repositories;
• scripts that trigger deployment or data migrations.

For German and European companies, this matters commercially and legally. Client projects, employee data, operational exports, and integration credentials often sit closer to development than anyone likes to admit.

If an AI agent can be tricked into modifying its own configuration, adding a tool, changing a startup file, or writing outside the intended repository, the local environment becomes part of the attack surface.

That is why “we do not let agents deploy to production” is not enough.

Production is not the only place where authority lives.

Repository Trust Becomes a Real Decision

Developers clone repositories all the time.

Open-source examples. Customer projects. Vendor demos. Boilerplates. Reproduction repos. Candidate take-home tasks. Internal experiments. Code shared in tickets.

Before agentic coding, opening an unfamiliar repo already carried some risk. But the common mental model was still mostly about whether the human ran code from it.

AI agents change that model.

If the agent reads repository files as task context, follows instructions in project docs, performs file operations, runs setup commands, or updates configuration, the repository is not passive input anymore. It can shape the agent’s behaviour.

Teams need clearer categories:

• trusted internal repositories;
• client repositories with contractual boundaries;
• third-party open-source repositories;
• untrusted reproduction cases;
• experimental generated code;
• downloaded examples and templates.

Those categories should change what an agent is allowed to do.

An agent working in a trusted internal service may be allowed to run tests and edit files in a narrow workspace. An agent inspecting an unknown open-source repo should run in a disposable environment with no secrets, no persistent agent config, no broad home-directory access, and no ability to modify trusted tool settings.

This sounds like overhead until you compare it with the alternative: every cloned repository quietly inherits the developer machine’s normal authority.

That is not architecture. That is convenience pretending to be architecture.

What Serious Teams Should Check

The practical response is not panic.

It is a short audit of the agent’s real authority.

1. Where Does Agent Configuration Live?

Find the files and directories that control agent behaviour.

That includes CLI config, MCP server definitions, tool allowlists, memory files, hooks, shell profiles, editor extensions, and project-level instruction files.

Then ask:

• Can a repository write to these paths?
• Can an agent modify them during normal work?
• Are changes to these files reviewed?
• Are global and project-level settings separated?
• Is there a way to reset them cleanly?

If agent configuration can be changed by project content, the team needs stronger boundaries.

2. Are Paths Resolved Before Approval?

A useful approval prompt should show the real operation, not only the apparent path.

For agent tooling, that means resolving symlinks and canonical paths before approval, enforcing workspace boundaries after resolution, and refusing writes that escape the intended scope.

Teams do not need every developer to become a filesystem security expert. But they should choose tools and workflows that take this seriously.

If a tool cannot make the real destination clear, treat approvals as advisory, not as a hard boundary.

3. Do Untrusted Repositories Run in Disposable Contexts?

Unknown repositories should not be opened with the same agent authority as core product repositories.

Use disposable containers, throwaway virtual machines, isolated worktrees, or separate user accounts for untrusted code. Keep secrets out. Mount only the directory required. Disable persistent tool configuration where possible. Avoid giving the agent access to the developer’s normal home directory.

The point is not to make development miserable. The point is to ensure that a bad repository can be deleted without wondering what else it changed.

4. Which Files Are Sensitive Even Outside Production?

Many sensitive files do not look dramatic.

Examples include:

• .env and .env.local;
• CI workflow files;
• package manager config;
• deployment scripts;
• auth and permission code;
• billing logic;
• migration scripts;
• MCP config;
• shell startup files;
• editor settings;
• credential helper configuration;
• generated client SDKs with endpoints or tokens.

Agent changes touching these paths should receive extra review. Not because agents are uniquely bad, but because speed increases the chance that a risky change looks routine.

5. Can the Team Reconstruct What Happened?

If an agent modifies files, runs commands, installs dependencies, or changes configuration, the team should be able to see what happened.

That means keeping useful logs: task prompt, files changed, commands run, tools called, dependencies added, configuration touched, and review decisions.

This is not bureaucracy. It is incident response for AI-assisted work.

When something odd happens, “the agent did something” is not a diagnosis.

The Founder and CTO Question

For leaders, the question is not whether a specific named exploit affects the exact version of a specific tool today.

That changes quickly.

The durable question is:

Where do we allow AI agents to convert project content into system action?

That is the boundary.

It appears in local development. It appears in CI/CD. It appears in support tools. It appears in internal admin systems. It appears wherever language, files, tools, credentials, and automation meet.

The companies that benefit most from AI-supported development will not be the ones that simply say yes or no to agents.

They will be the ones that separate contexts clearly:

• fast, low-risk spaces for experimentation;
• bounded development workflows for product code;
• reviewed pathways into shared branches;
• narrow interfaces to CI/CD;
• strict handling of secrets and config;
• explicit ownership of agent tooling.

That is how teams keep the speed without turning every convenience feature into invisible authority.

How McDougall Digital Helps

At McDougall Digital, this is exactly the kind of place where we think architecture-first AI adoption matters.

The goal is not to slow teams down with theoretical risk documents. The goal is to make the fast path safer and clearer:

• map where agents can read, write, execute, and call tools;
• separate trusted and untrusted repository workflows;
• review local and CI/CD credential exposure;
• design path and workspace boundaries;
• define rules for MCP servers and agent configuration;
• add review gates for sensitive files;
• create an operating model developers can actually follow.

AI coding agents are useful. Used well, they can make serious software teams faster.

But the approval prompt is not the boundary.

The boundary is the architecture around it.