Picture an incident channel lighting up at two in the morning. An agent installed code or touched a production system, and the prompt that triggered it looks completely ordinary. So where did the instruction actually come from, and what gave it the authority to act?
In an agentic system, the answer rarely lives in the prompt. It lives in the repository files the agent reads, the skills it has installed, and the identity it inherited to do any of it. If a source can shape what the agent does, or enable what it can execute, it belongs in your supply-chain and control-plane review.
Influence Versus Authorization in Agentic AI Systems "Agentic" doesn't need a strict product definition here. Treat a system as agentic the moment a model can choose and use tools under an identity, whether that's a coding assistant looping inside an IDE or a scheduled job quietly holding onto whatever authority it was given.
Across both of those, the same attack surface applies. Repository instructions, retrieved pages, and installed skills can all shape what a model intends to do, the mechanism generally known as indirect prompt injection . Intent alone rarely does the damage. What decides whether that intent becomes a real action is the identity, tools, credentials, and approval policy behind it, the same line that runs through the agentic AI attack surface .
That distinction gives you a simple test for any agent incident:
What supplied the intent? What authority turned it into an action? What actually changed as a result? Three demonstrations show how that plays out in practice.
Case 1: AGENTS.md and Agent Goal Hijack The setup is an ordinary VS Code workspace with a root AGENTS.md file , the kind of instruction file a lot of coding agents apply automatically to every request. A malicious version of that file plants a recurring objective before the user has asked for anything. The user then sends a single character, and that's enough to activate it.
An approval prompt does appear, the best-case outcome here. But the prompt shows only a short shell wrapper. Decoding what the wrapper really does reveals a local file read followed by outbound delivery: a quiet exfiltration path the user never knowingly approved.
This maps to OWASP's Agent Goal Hijack and Tool Misuse categories. No amount of prompt engineering solves this. Instruction files need to be treated like privileged config, protected the way you'd protect any file that can steer a production system, with approval prompts that show the real destination and payload instead of a friendly summary.
Case 2: Marketplace Skills and Dependency Hijack This one starts with a real, conscious choice: a developer installs a plugin from an unofficial marketplace to bootstrap new project environments with one command. That choice isn't the vulnerable step.
The vulnerable step happens later, when running that command hands the sourcing decision to the installed skill instead of the person who typed it. The skill quietly points a package install at a substituted Git source, and ordinary package tooling does exactly what it's told. In the demonstration, the workflow still reports "setup complete" even after a tainted build lands in the wrong place. A tainted package that warns you is a courtesy. A real one would stay silent.
This is a supply chain failure wearing an agent costume, the exact pattern OWASP's Agentic Skills Top 10 catalogs as a named risk. The fix looks like standard dependency hygiene, just extended to cover what agents and skills are allowed to install: approved sources only, pinned versions, no shortcuts through unofficial channels. The same pattern shows up in Claude Code marketplace skills , where a plugin can quietly swap a trusted dependency for a trojanized build.
Case 3: Instruction File Integrity and Its Limits Not every case here is an attack: ClawSec is an open-source tool that baselines an agent's trusted instruction files, detects when they've been tampered with, and restores the approved version. In a demonstration, a planted hook alters a trusted file, the same kind of goal hijack Case 1 showed happening through a repository instead. Without the monitor, the change sticks. With it, the tampering is caught and the file is restored.
The honest caveat matters more than the recovery: restoring a file isn't the same as recovering a session. Whatever the agent already read, remembered, or acted on before detection is still in play. Getting the file back is only the opening move. A full response also means restarting sessions and reviewing what happened during the window the file was compromised. It's also a reminder to put approval gates on the actions an agent takes, in addition to protecting the instruction files that steer it.
Beyond Coding Agents: Browser Sessions and Software Supply Chains Inside a browser session, the same intent-versus-authority test still applies: content on a page can propose an action, but an authenticated session shouldn't turn that proposal into a transaction without its own check. It isn't limited to agents either.
In March 2026, a compromise of Trivy's release pipeline exposed publishing credentials, and malicious versions of LiteLLM appeared on PyPI within days. That particular incident was contained, with impact limited to some leaked API keys. But LiteLLM and tools like it have become a crucial part of the agentic supply chain: for many organizations, this kind of software controls which skills are available, which inference endpoints get used, and which models an agent can reach. A more sophisticated version of this attack could reach further, reconfiguring the LLM access an entire organization's agentic workforce depends on. The Trivy-to-LiteLLM incident shows the publishing path itself acting as the attack surface. Traditional supply chain attacks may be tomorrow's agentic control-plane attacks.
The Test That Ties It Together Influence on an agent is inevitable. Given enough time, something will eventually try to shape what it does. Unbounded authority in response to that influence is optional, and it's the part actually within a team's control.
So the test is simple: if an agent acted at 2am, could you prove under whose authority it acted, what exact request ran, and what actually changed? If the answer is no, look past the model. The gap has been sitting in the control plane behind it the whole time.
