You download a GitHub repository, open it in your AI coding agent, and type:
> “Take a look at this project and fix the authentication bug.”
That's a normal developer workflow now.
The agent starts inspecting files. It runs git status. It reads the project structure. It checks dependencies. Maybe it runs tests.
You didn't run any suspicious command.
But what if the repository itself was designed to make the agent run one?
That isn't science fiction.
In September 2026, security researchers disclosed a class of vulnerabilities dubbed GitSpawn, affecting multiple AI coding agents including Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build, and Hermes Agent. The problem involved malicious Git configuration causing commands to execute when the agent performed routine Git operations. In several cases, the command could run as the developer's user, outside the agent's sandbox and without an approval prompt.
That's a different security problem from “AI generated some vulnerable code.”
Now the AI developer tool itself becomes part of the attack surface.
And if you're using an AI coding agent every day, that's worth understanding.
Your AI coding agent has more access than your chatbot
A normal chatbot mostly gives you text.
A coding agent is different.
Depending on the tool and configuration, it may be able to:
- Read your repository
- Modify files
- Run shell commands
- Execute tests
- Use Git
- Install packages
- Access environment variables
- Connect to APIs
- Read configuration files
- Interact with your filesystem
- Sometimes access the network
That's incredibly useful.
It's also why the security model is different.
If I ask a chatbot:
> “Explain this JavaScript function.”
the worst outcome is usually a bad explanation.
If I ask a coding agent:
> “Fix the dependency problem and run the tests.”
the agent may execute commands on my computer.
The trust boundary has moved.
The agent isn't just generating text anymore. It's operating inside an environment that contains things I care about.
That's why AI coding agent security isn't just an AI safety problem.
It's a developer workstation security problem.
The GitSpawn flaw is a perfect example
The recent GitSpawn disclosures are interesting because the attack doesn't require some futuristic AI trick.
It abuses something much more ordinary.
Git has configuration options that can tell it to use helper programs. One example involved core.fsmonitor, a legitimate Git performance feature.
The researchers found that a malicious repository could contain configuration that points this setting at an attacker-controlled command. AI coding agents routinely run Git commands in the background to understand a repository.
So the sequence can look roughly like this:
Developer receives repository
↓
Opens it in AI coding agent
↓
Agent runs a normal Git command
↓
Git reads repository configuration
↓
Configured helper executes
↓
Attacker-controlled code runs
The developer may never consciously approve a shell command.
That's what makes this interesting.
The vulnerability isn't really “AI is evil.”
It's the interaction between Git's trusted behavior and an automated agent that executes Git operations without the developer thinking about them. The Cloud Security Alliance's research describes this exact trust-boundary problem.
And the affected versions weren't obscure experimental tools only. The disclosures included Claude Code, Codex, Cursor and several other widely used coding agents.
Some fixes have already shipped, while other affected paths were still being investigated or unpatched when researchers retested them in early September.
That's why “I only open trusted-looking repos” isn't a complete security strategy.
A sandbox is useful. It isn't magic.
Most modern coding agents try to reduce risk with sandboxes, permissions, approval prompts, or restricted environments.
That's good.
You should use them.
But don't interpret:
> Sandboxed
as:
> Impossible to compromise
A separate August 2026 disclosure involving DeepSeek Harness makes this point particularly well.
Researchers reported that its run_code path could execute model-generated TypeScript outside the intended file-effect sandbox, allowing file access and process execution beyond the restrictions that were supposed to apply.
A separate analysis reported CVE-2026-82533 involving a sandbox escape in DeepSeek Harness, where an agent could use an internal API to move from a restricted environment to a more privileged execution mode.
DeepSeek's own safety documentation is unusually clear about this. It says the project is experimental, hasn't undergone a security audit, and warns that sandboxing and approval controls don't guarantee isolation. It recommends least privilege and disposable environments for untrusted workloads.
That's exactly the mindset developers should have.
A sandbox reduces blast radius. It doesn't make untrusted code trustworthy.
Your .env file is suddenly much more interesting
Here's where this becomes a real problem for website owners.
Imagine your local project contains:
.env
with:
DATABASE_URL=...
STRIPE_SECRET_KEY=...
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
You normally think:
> “It's fine. .env isn't committed to Git.”
Maybe.
But your AI coding agent may be able to read it.
That's sometimes necessary. Your application needs the variables.
But now imagine you open an untrusted repository in the same environment.
Or you give an agent access to a directory containing multiple projects.
Or you run the agent from a machine where SSH keys, cloud credentials, deployment tokens, and browser credentials are available.
The security question changes from:
> “Can this AI write vulnerable code?”
to:
> “What happens if this agent, or something it opens, gets compromised?”
That's a much more useful question.
A developer workstation can contain credentials for:
- GitHub
- Cloud providers
- Production servers
- Databases
- Stripe
- DNS providers
- CI/CD systems
- Private package registries
If the agent can reach those credentials, a compromise can become much larger than the repository you're currently editing.
Website owners should care about this too
You might be thinking:
> “I'm not a developer. Why should I care about GitSpawn?”
Because your website may have been built by someone using an AI coding agent.
And that developer may have access to your production environment.
This creates a supply-chain problem.
Imagine your freelance developer builds your website using an AI coding agent.
Their machine has:
GitHub access
↓
Cloud hosting access
↓
Database credentials
↓
Deployment token
↓
Production server
If their development environment gets compromised, the attacker doesn't necessarily need to attack your website directly.
They may already have a path through the person who maintains it.
This is why website security isn't only about what happens on the server.
The development environment matters too.
For a business owner, I'd ask a developer a few simple questions:
Where are production credentials stored?
Does the AI agent have access to them?
Can the agent deploy directly to production?
Is there a separate staging environment?
Are deployment credentials short-lived or permanent?
Can the developer revoke the agent's access without changing everything else?
You don't need to understand Git internals to ask those questions.
What I'd change if I use an AI coding agent every day
I wouldn't stop using one.
That would be the wrong lesson.
I'd change the environment around it.
Keep production credentials away from the agent
Your coding agent shouldn't casually have your production database password just because the project happens to use a database.
Use separate development credentials whenever possible.
For deployment, prefer short-lived credentials or tightly scoped tokens instead of a permanent master key.
Use least privilege
If an agent only needs read access to a repository, don't give it write access.
If it needs to modify staging, don't give it production deployment access.
If it needs one API, don't give it access to your entire cloud account.
This isn't complicated security theory.
It's limiting how bad things can get when something goes wrong.
Treat unfamiliar repositories as untrusted
This is the biggest lesson from GitSpawn.
Before handing an unfamiliar repository to an automated coding agent, inspect its Git configuration.
For example:
git config --get core.fsmonitor
And if you've received a directory containing an existing .git folder, inspect:
cat .git/config
Look for unusual entries involving things such as:
core.fsmonitor
core.hooksPath
filter
process
The exact indicators depend on the vulnerability and agent you're dealing with, so don't treat one command as a complete security scanner.
The point is to stop thinking of a Git repository as “just source code.”
It can contain configuration that changes how Git behaves.
Keep the agent updated
This sounds boring.
Do it anyway.
The GitSpawn disclosures included fixes for several affected products and versions. For example, The Hacker News reported fixes for Goose, Codex CLI, and the affected Claude Code core.fsmonitor path, while other paths and products were still being addressed at the time of reporting.
If your coding agent is part of your development environment, it belongs in your patching routine.
Not just your browser and operating system.
Don't let “approval required” become your only defense
Approval prompts are useful.
But you can't build a security model around assuming you'll notice every dangerous command.
Modern agents run many background operations.
Git commands.
Package managers.
Tests.
Build tools.
Linters.
Scripts.
The safer approach is to reduce what the agent can access in the first place.
If an agent doesn't have access to production credentials, compromising the agent is much less useful to an attacker.
AI-generated code and AI-agent security are two different problems
This distinction is worth making.
We've spent a lot of time talking about AI-generated vulnerabilities.
For example:
const user = await db.query(
`SELECT * FROM users WHERE id = ${req.params.id}`
);
That's an application security problem.
You need code review, testing, scanning, and proper parameterized queries.
But GitSpawn is different.
The generated application might be perfectly secure.
The tool you used to build it can still have a security problem.
That's why developers now need to think about two separate layers:
AI coding environment
↓
Source code + dependencies
↓
Build / CI
↓
Deployed application
↓
Website / API / users
Every layer has its own security boundary.
And fixing only the application isn't enough if the development environment can leak the credentials used to deploy it.
The practical workflow I'd use
If I'm building a production website or SaaS with an AI coding agent, I'd keep the workflow simple.
1. Build in an isolated development environment.
Don't give the agent your entire home directory.
2. Use non-production credentials.
Development database. Development API keys. Development cloud account where possible.
3. Treat unfamiliar repositories as untrusted.
Especially before opening them with an agent that can execute commands.
4. Keep the coding agent updated.
Security fixes are part of the tool's lifecycle.
5. Scan the code before deployment.
Check dependencies, secrets, dangerous patterns, and known vulnerabilities.
6. Test the deployed application separately.
Source code can look fine while the running application has broken authorization, exposed endpoints, or bad configuration.
7. Keep production behind another security layer.
WAF, access controls, monitoring, logging, backups, and properly scoped deployment credentials all reduce the blast radius.
This is where I think the industry needs to move.
Not away from AI coding.
Away from the idea that “the AI wrote it, so the AI checked it.”
Those are two different jobs.
The new rule for vibe coding: trust less, test more
AI coding agents are becoming part of normal software development.
That's not going away.
And honestly, it shouldn't.
They make developers dramatically faster.
But speed changes the economics of security. When an agent can create hundreds of files, modify infrastructure, install dependencies, run commands, and deploy applications in a short session, there are simply more actions happening inside your trust boundary.
The recent GitSpawn disclosures show that even something as ordinary as Git configuration can become an unexpected execution path when combined with an automated coding agent.
The DeepSeek Harness disclosure shows another side of the problem: a sandbox is only as strong as every execution path inside the system.
And for website owners, the lesson is simple.
You don't need to understand every AI security vulnerability.
You need to know who or what has access to your code, credentials, deployment pipeline, and production environment.
Then put boundaries between them.
Once the application is built, don't stop at “the site works.”
Scan the code.
Check the dependencies.
Test the deployed application.
Monitor SSL, uptime, vulnerabilities, and important user flows.
That's the security lifecycle an AI-built website needs.
If you're building with AI and want to see what an external security check can find on your deployed site, run a free scan before handing the application to real users.
And if you're a developer using an AI coding agent today, check its version, review the security advisories for your exact tool, and keep production credentials out of the agent's reach.