AI Agent Security Risks: Why Coding Agents Keep Breaking Trust Boundaries
AI coding agents have had a difficult few months for security.
In July, researchers demonstrated that a public GitHub issue could manipulate an agent into retrieving information from a private repository. Another piece of research showed how symbolic links could undermine the approval controls used by six different coding assistants. Separately, developers have reported coding agents executing destructive database operations without adequately signaling the consequences.
These look like different problems.
Prompt injection. Filesystem vulnerabilities. Excessive database permissions. Unsafe tool execution.
But underneath them is a common architectural problem: we are giving agents access across trust boundaries without putting strong enough controls between them.
Read and write. Public and private. Development and production. Project files and system files. Routine operations and destructive ones.
For traditional applications, we have spent decades separating these boundaries.
With AI agents, we are starting to collapse them again.
That is the part worth paying attention to.
The most important AI agent security risks are therefore not entirely new vulnerabilities.
They are familiar security failures appearing in systems with far greater autonomy
1. GitLost: When Public Input Reached Private Data
In July 2026, Noma Security disclosed GitLost, a prompt-injection attack against GitHub Agentic Workflows.
The attack did not require stolen credentials or access to the target repository. An attacker could place instructions inside a public GitHub issue. If an agentic workflow processing that issue also had access to private repositories, the injected instructions could cause the agent to retrieve private content and expose it through a public comment.
The model was not really the security boundary.
The permissions around it were.
The workflow combined three capabilities that should immediately make a security architect uncomfortable:
it consumed untrusted public input
it could access private information
it could publish information back to a public channel
Once those capabilities existed inside the same execution context, prompt injection provided a path between them.
The architectural lesson
An agent processing a public issue should not automatically inherit access to private repositories simply because the user or organisation running it has that access.
Access should be scoped to the task.
If information from another repository is genuinely required, retrieve the specific information through a controlled mechanism rather than giving the agent standing access to everything.
The same principle applies to enterprise data platforms.
An agent answering questions from a broadly accessible interface should not automatically inherit access to every dataset its operator can see.
Untrusted input and privileged data access should not exist inside the same unrestricted agent context.
2. GhostApproval: When the Approval Screen Wasn't the Security Boundary
Also in July, Wiz disclosed a class of symlink vulnerabilities it called GhostApproval.
The research covered six AI coding assistants: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity and Windsurf.
The problem was subtle.
A malicious repository could contain a symbolic link that appeared to point to an ordinary project file but actually resolved to a sensitive file elsewhere on the developer's machine.
An agent might ask:
Approve modification of project_settings.json?
The developer sees a harmless-looking project file and approves it.
But after the operating system resolves the symbolic link, the actual write could land somewhere entirely different — potentially a shell configuration file, SSH configuration or another sensitive location outside the project.
This matters because human-in-the-loop approval is increasingly treated as the answer to agent security.
GhostApproval demonstrates why that is not enough.
The architectural lesson
An approval is only meaningful if the thing being approved is the thing that will actually happen.
Before presenting an operation for approval, the system needs to resolve the real target and enforce the filesystem boundary itself.
For file operations that means controls such as:
canonical path validation
rejecting links that resolve outside the permitted workspace
isolating agent execution inside containers or sandboxes
limiting access to sensitive filesystem locations
The important distinction is between asking a human whether something is safe and architecturally preventing the unsafe operation.
Human approval should be another control, not the primary security boundary.
3. Claude Code and Supabase: Destructive Actions Need Different Controls
In April 2026, a Claude Code user reported that the agent executed:
npx supabase db resetwhile attempting to apply a database migration.
The command reset the local Supabase database and destroyed manually curated data that had not been backed up.
This was not a sophisticated security exploit. It was arguably a more useful warning because of that.
The agent was trying to complete a legitimate task.
It selected a destructive command where a non-destructive migration command should have been used, and the environment allowed it to execute.
The failure was therefore not simply that the model made the wrong decision.
The surrounding system allowed one incorrect decision to become data loss.
The architectural lesson
Routine and destructive operations should not share the same execution path.
Commands such as:
DROP
TRUNCATE
DELETE
database reset operations
destructive filesystem commands
production configuration changes
should be treated differently from normal reads, builds and migrations.
That can mean explicit approval, restricted credentials, environment-specific policies or deterministic command controls outside the model.
The broader rule is:
the potential impact of an operation should determine the strength of the control around it.
4. Agents Should Not Be Able to Change Their Own Security Boundary
Model Context Protocol servers and similar tool integrations introduce another architectural question.
What happens when the configuration defining an agent's capabilities is itself inside the agent's write scope?
An MCP configuration can determine which directories, APIs, databases or tools an agent can access.
If the agent can modify that configuration as easily as it modifies application code, the security boundary becomes circular:
the thing being constrained can modify the constraint.
Whether the change is malicious is almost irrelevant.
An agent trying to complete a task may encounter an access restriction and reasonably conclude that changing a configuration file is the easiest way around it.
That is normal problem-solving behaviour.
It is terrible privilege design.
The architectural lesson
Security configuration needs to exist at a different privilege level from agent-controlled content.
An agent may need to read its configuration.
It generally should not be able to modify it.
Changes to tool permissions, MCP servers, service-principal grants or production access should instead go through a separate control path; ideally version controlled, reviewed and deployed independently.
This is the same pattern we already use for infrastructure and identity management.
A workload should not be able to rewrite the IAM policy controlling that workload.
AI agents should be treated the same way.
5. The Agent's Credential Matters More Than the Model
A recurring mistake in agent deployments is allowing the agent to operate using the credentials of the person running it.
That is convenient.
It also means the agent may inherit everything the developer can do.
If the developer can read production data, modify schemas, access multiple repositories and execute administrative commands, the agent may effectively receive the same authority.
That dramatically increases the consequences of prompt injection, reasoning errors and compromised external content.
A safer pattern is to treat an agent as its own workload identity.
What that looks like
The agent receives a dedicated service principal or equivalent machine identity.
That identity gets only the permissions required for the task.
For example, a data agent may be allowed to:
read approved production datasets
create or modify objects in a development schema
execute a defined set of functions or tools
It does not automatically receive every permission belonging to the developer invoking it.
This is not a new AI security concept.
It is ordinary least-privilege architecture applied to a new type of workload.
And it substantially reduces the blast radius when the agent does something unexpected.
6. Context Is Becoming a Security Boundary
One of the less visible risks with agents is where their context comes from and where it goes.
Modern agents may combine information from:
source repositories
databases
ticketing systems
documentation
observability platforms
MCP servers
external APIs
user prompts
third-party integrations
From the model's perspective, this can appear as one large context.
From a security perspective, it absolutely should not.
A public GitHub issue is not equivalent to a private repository.
A production customer table is not equivalent to documentation.
An error message from an external system is not equivalent to an instruction from the user.
And information retrieved from a regulated dataset should not automatically be allowed to flow into an external integration.
The architectural lesson
Agent architectures need to preserve the classification and trust level of information as it moves through the system.
That means thinking about:
Source - Where did this information come from?
Trust - Is it an instruction or untrusted external content?
Classification - Is it public, internal, confidential or regulated?
Destination - Where is the agent about to send it?
Authority - Does the agent actually need access to it?
This is where existing governance capabilities such as RBAC, attribute-based access control, data classification and audit logging become increasingly important.
The model should not be expected to enforce these boundaries by reasoning about them.
The platform should.
What Governed Agent Architecture Looks Like
The incidents are different, but the defensive architecture is surprisingly consistent.
1. Give agents their own identities
Do not automatically run agents with the full credentials of the human invoking them.
Use dedicated workload identities with least-required privileges.
2. Separate read from write
An agent that needs to analyse production data does not necessarily need permission to modify it.
Read access and write access should be separate decisions.
3. Treat destructive actions differently
Database resets, deletes, schema changes, production deployments and sensitive filesystem writes need stronger controls than routine operations.
4. Keep security configuration outside agent control
Agents should not be able to modify the policies, credentials or tool configuration defining their own permissions.
5. Enforce trust boundaries outside the model
Do not rely on a system prompt saying:
"Never access private data."
Make the private data inaccessible unless the task genuinely requires it.
6. Validate what the human is approving
Approval interfaces should display the resolved resource and actual operation, not simply the agent's description of what it intends to do.
7. Preserve data classification through the agent
Public, internal, confidential and regulated information should remain distinguishable even when all four appear in an agent workflow.
8. Log agent actions as workload activity
You should be able to answer:
Who executed the action?
Which agent?
Using which identity?
Against which resource?
What tool was called?
Was approval required?
What happened?
Without that audit trail, investigating an agent incident becomes unnecessarily difficult.
The Australian Governance Question
This is becoming increasingly relevant for Australian organisations as the federal government develops a more formal national approach to AI governance.
The establishment of the Office of AI in July 2026 and the government's work toward further AI legislation make it increasingly difficult to treat agent security as simply a developer tooling decision.
But I don't think organisations need to wait for the final legislation to know what good architecture looks like.
The useful questions already exist:
What identity does the agent operate as?
What systems can it access?
What can it read?
What can it modify?
Which actions require approval?
Can it change its own permissions?
Can untrusted content influence privileged actions?
Can sensitive information cross into a less trusted destination?
Are its actions independently logged?
Can we revoke its access without affecting a human user?
Those are architecture questions before they are AI questions.
The AI Agent Security Risks Behind These Incidents
GitLost was a prompt-injection problem.
GhostApproval was a filesystem and approval-boundary problem.
The Supabase incident was a destructive-action problem.
Other agent failures will look different again.
But focusing on individual vulnerabilities risks missing the larger lesson.
The model does not need to be malicious for an agent to cause damage.
It only needs:
access to something sensitive
the ability to take consequential action
a path by which an incorrect or manipulated decision becomes execution
Good agent architecture breaks that chain.
The goal isn't to make the model incapable of making a mistake.
That isn't realistic.
The goal is to design the surrounding architecture so that one bad decision cannot automatically become a security incident.
That is a much more achievable standard - and one we already know how to engineer.
This article was written by Keith Jenneke, Principal Consultant at Cypher Agency. Keith leads Cypher's Data, Integration, and AI Engineering practice, building governed Modern Data Platforms that make data reliable, integrated, and analytics- and AI-ready, delivered across professional services, resources, and government sectors in Australia.
Comments