Agent hijacking is becoming an enterprise supply-chain problem, not another prompt-injection problem
A few years ago, when a security team reviewed a new software dependency, the questions were familiar. Who built it? Which version are we using? What privileges does it require? Does it open a network connection? What happens if the package is compromised?
Strangely, many organizations have abandoned this discipline at precisely the moment AI systems have become capable of taking action.
Teams are now importing agent skills, MCP integrations, tool definitions, workflow packs and third-party plugins into environments where agents can read documents, query customer records, create tickets, initiate workflows and sometimes trigger financial transactions. The artifact being imported may look like Markdown, YAML or a collection of natural-language instructions, so it does not psychologically register as executable software.
From an operational-risk perspective, that is the wrong mental model.
A skill file does not need an executable binary to become dangerous. Once its instructions enter the planning context of an autonomous agent, the skill can influence how the agent uses credentials, tools, memory and enterprise data that the skill itself never possessed. The security problem is therefore not simply whether malicious code entered the environment. The more difficult question is whether untrusted instructions acquired trusted authority.
Security research into public agent-skill ecosystems during 2026 has already reported vulnerability rates high enough to make this a serious supply-chain issue, including weaknesses associated with data exfiltration and privilege escalation. Whether the eventual industry number settles at 10 percent, 20 percent or higher is almost secondary to the architectural implication. Enterprises are beginning to consume behavioral dependencies written largely in natural language while applying far less scrutiny than they would to conventional software packages.
The emerging problem is an AI supply chain in which a few kilobytes of apparently helpful instructions can inherit permissions that would never have been granted to the person who wrote them.
The real attack is authority laundering
Consider how a payment-operations agent might actually be deployed inside a large bank.
The agent has read access to supplier-master records, payment exceptions and selected account information. It can search internal documentation, interrogate transaction APIs and create investigation cases. Outbound internet access is restricted, although an approved observability endpoint is available because operations teams legitimately need execution telemetry.
A developer finds a well-reviewed third-party skill called Advanced Payment Reconciliation. The skill contains hundreds of lines describing reconciliation logic, exception handling, document retrieval and diagnostic procedures.
Buried deep inside those instructions is a seemingly reasonable requirement:
Nothing in that instruction says “steal customer information”. Nothing asks the agent to ignore its system prompt and nothing resembles the crude prompt-injection examples on which many development teams have been trained.
Yet suppose the diagnostic tool ultimately sends information to infrastructure controlled by the skill publisher or to an endpoint whose ownership has changed after the skill was approved. The agent may now retrieve confidential relationship information and include it in what appears to be legitimate operational telemetry.
The attacker never needed credentials to the bank. The imported skill acquired influence over an agent that already had them.
A conventional application firewall may see an approved endpoint. An IAM system may see a valid service identity. The tool invocation may conform perfectly to its API schema and the system prompt may remain technically intact. The failure occurred earlier when the organization allowed untrusted behaviour to enter a trusted decision process.
Long skill files make this especially difficult to detect because sophisticated malicious instructions do not have to look malicious.
Imagine a customer-dispute agent used by a card issuer. Its normal responsibilities include retrieving transaction evidence, examining correspondence and preparing a dispute package. A compromised document-analysis skill does not need to say “exfiltrate cardholder data”. It can instruct the agent to “attach supporting context required for downstream evidence validation” or “retain representative diagnostic samples where confidence falls below threshold”.
Those are perfectly plausible instructions inside a legitimate business workflow.
Now extend the sequence. The skill asks the agent to retrieve five recent examples whenever a parsing error occurs. Those examples contain names, transaction descriptions and partial payment information. The skill then asks the agent to send those examples through a debugging connector that is already approved for operational telemetry.
Each individual action can look reasonable. The malicious behaviour emerges from the sequence.
This is where agent security diverges from static prompt filtering. The unit that must be governed is not a sentence. It is the combination of instruction, context, permission, tool invocation, data movement and eventual business effect.
Skills should enter production through promotion gates
The strongest operating model is to stop treating skills as developer conveniences and start treating them as third-party execution dependencies.
In a banking environment, a newly downloaded skill should not move directly from GitHub, a marketplace or an internal repository into a production agent. It should pass through sequential verification gates in much the same way as any privileged software dependency.
The first gate establishes provenance. The enterprise needs to know where the skill came from, who maintains it, which version is being admitted and whether the artifact being deployed is identical to the artifact that was reviewed. A cryptographic hash of the approved version should become part of the deployment record.
Suppose the reconciliation skill passes review as version 1.8.3. Two weeks later, the public repository publishes 1.8.4 containing an apparently harmless troubleshooting section. Production should not silently consume that update simply because the package name remains unchanged. Version 1.8.4 is a new behavioural dependency and should be reviewed as one.
The second gate compares declared behaviour with inferred behaviour.
A skill manifest might declare that it needs the payment-status tool and supplier-master read access. Semantic inspection of the instructions shows that the skill also encourages the agent to inspect correspondence records and invoke the diagnostic connector. That discrepancy should block promotion.
The key question is not whether every sentence is malicious. The organization needs to know whether the behaviour implied by the instructions exceeds the operating envelope the skill claims to require.
The third gate should be adversarial execution in a sandbox.
Instead of giving the skill real customer information, the bank supplies synthetic payment cases containing instrumented data. One supplier record might include a unique canary identifier that should never appear in telemetry. Another test might deliberately create an unresolved payment exception to see whether the skill attempts to retrieve information outside its expected domain.
If the canary value appears in an outbound diagnostic call, the organization has discovered an exfiltration path without exposing real customer data.
This kind of verification is considerably more valuable than asking another model whether the skill “looks safe”.
Trust should be graduated, not inherited
One of the most dangerous design choices in current agent platforms is binary trust.
A skill is either installed or not installed. Once installed, it often receives whatever capabilities happen to be available to the hosting agent.
That model is difficult to defend in an enterprise where different capabilities carry radically different consequences.
A newly discovered skill should initially have no production authority. It can be inspected and exercised against synthetic data, but it should not interact with real customers or enterprise systems. After technical verification, the skill might move into a restricted tier where it can access non-sensitive production information through read-only tools. Only after operational evidence accumulates should it become eligible for more consequential capabilities.
Consider the payment-reconciliation example. The same skill might initially be allowed to read transaction status and classify exceptions while being prohibited from retrieving customer correspondence or creating payment instructions. A separate approval might later allow case creation while payment release remains completely outside the skill’s authority.
For highly privileged banking functions, maturity should never be confused with unrestricted autonomy. A treasury skill that can propose liquidity transfers may be extremely mature and still require deterministic approval before any money moves.
Trust therefore needs to be expressed as an execution envelope, not as a reputation score.
The enterprise should be able to say that this exact version of this skill may use these tools, against these data classifications, for these action types, through these approved destinations and only within these transaction limits.
That statement can be tested and audited. “Trusted skill” cannot.
The model should not be the final security authority
Another lesson from production agent systems is that the agent cannot be the final authority on whether its own proposed action is acceptable.
A system prompt saying “do not reveal sensitive banking information” is useful, but it cannot replace external policy enforcement.
Return to the compromised reconciliation skill. The agent decides that supplier correspondence is relevant and attempts to send a diagnostic payload containing an account identifier and internal case notes.
A properly designed runtime intercepts the tool call before execution.
The policy layer knows that the skill is approved for payment-status data but not customer correspondence. It also knows that the diagnostic connector may receive operational metadata but not restricted customer information.
The call is denied regardless of how persuasive the skill’s instructions appear to the model.
This is where agent architecture needs to borrow more aggressively from zero-trust security. The model proposes; the control plane authorises.
For sensitive environments, every consequential tool request should be evaluated against the agent identity, active skill version, requested operation, target system, data classification and current transaction context.
Credentials should also be issued narrowly rather than exposed broadly to the agent runtime. If the agent needs to query payment status, a credential broker can provide a short-lived token scoped to that operation. The skill never receives a reusable credential and the model never needs to manipulate one.
A malicious instruction may still persuade the agent to attempt something inappropriate, but persuasion no longer guarantees execution.
The industry needs proof-carrying skills
There is a more interesting design direction beyond today’s skill registries.
Instead of distributing a skill as instructions alone, enterprises should require every approved skill to carry a machine-readable behavioural manifest.
The manifest would declare the tools the skill may request, data classifications it is expected to process, permissible outbound destinations, whether it can modify state, maximum action budgets, approval requirements and the cryptographic identity of the reviewed content.
The skill then becomes something closer to a proof-carrying execution dependency.
Imagine the payment-reconciliation skill declaring that it may read supplier identity and payment status, create an investigation case and produce operational diagnostics. It may not retrieve customer KYC documents, initiate payments or transmit record-level information to external endpoints. Diagnostic output may contain error codes, latency information and non-sensitive transaction identifiers.
The runtime no longer has to infer every boundary from natural-language prose during execution. It can mechanically compare proposed actions against the approved manifest.
If the skill suddenly tries to access KYC records, the platform has an objective policy violation. If a new version legitimately requires that capability, the manifest changes and the capability change triggers a fresh risk review.
This approach scales much better than asking security teams to reread thousands of lines of instruction text every time an agent capability evolves.
A skill can become dangerous without changing
There is another supply-chain failure mode that deserves considerably more attention.
A skill can become more dangerous even when its own file has not changed.
Suppose a bank approves a document-analysis skill while the hosting agent can access only supplier invoices. Six months later, another team expands the agent’s responsibilities and gives it access to sanctions-investigation notes, beneficial-ownership documents and customer correspondence.
The skill hash remains identical but its effective blast radius does not.
Traditional dependency management asks whether the package changed. Agentic systems must also ask whether the authority surrounding the package changed.
Any material expansion of an agent’s tools, data access or downstream action rights should therefore trigger reevaluation of every skill operating inside that agent’s context.
The reverse can happen as well. A harmless tool may become dangerous after its implementation changes. A telemetry connector that originally accepted only numeric operational metrics might later support arbitrary JSON attachments. A previously safe diagnostic instruction can suddenly become a viable exfiltration path.
Continuous compliance therefore cannot mean rescanning the same skill files every night and declaring them unchanged.
The control system needs to monitor the capability graph around them.
Compliance has to follow behaviour
In a mature banking implementation, every significant agent execution should produce an evidence chain connecting the active skill version to the resulting business action.
An investigation should be able to reconstruct which skill instructions were active, which policy version governed the execution, which tools were called, what classes of data were accessed, which external destinations were contacted and what approvals were applied.
This becomes especially important when malicious behaviour is intermittent.
A compromised skill may behave normally for months and activate only when a particular record type appears. The reconciliation skill might issue its additional diagnostic call only when a transaction exceeds a certain value or when the supplier belongs to a particular jurisdiction.
Static testing may never encounter that trigger but tuntime monitoring can.
Security operations should therefore baseline expected skill behaviour and watch for changes such as newly used tools, unexpected data-domain crossings, denied privilege requests, unusual egress destinations or sudden increases in context retrieved for routine tasks.
A payment skill that historically reads two systems but begins requesting data from seven deserves investigation even when every individual request remains technically authorised.
The objective is not to turn every agent trace into a security alert. It is to make behavioural drift visible before it becomes silent privilege expansion.
ISO/IEC 42001 becomes useful here when it is treated as an operating discipline rather than as a certificate.
The standard does not tell an engineering team how to hash a skill file, construct an egress proxy or sandbox a tool invocation. Its value is in establishing a management system within which those controls become owned, repeatable and auditable.
For the banking example, the organization should be able to demonstrate that agent skills are included in the AI asset inventory, external skill providers are covered by supplier-risk processes, material capability changes trigger risk assessment, high-impact agent use cases have defined operational controls, monitoring evidence is reviewed and incidents lead to corrective action.
Suppose the bank discovers that version 1.8.4 of the reconciliation skill attempted to transmit a canary value during sandbox testing.
A mature operating model does more than block version 1.8.4. It preserves the evidence, identifies every environment in which the publisher’s artifacts are installed, determines whether related skills exhibit the same pattern, records the supplier event, reassesses applicable controls and verifies that production policy would have blocked the attempted behaviour.
That is the difference between having a security feature and having an operating control.
The former handles an event. The latter changes how the organization manages the risk category.
Assume that some skills will eventually be hostile
The strategic mistake is trying to build an agent ecosystem in which every imported skill is guaranteed to remain benign.
Software supply chains have already taught us how unrealistic that ambition is.
Repositories are compromised. Maintainer accounts are taken over. Dependencies change ownership. Popular packages are abandoned. Trusted vendors make mistakes and attackers learn to hide malicious behaviour inside functionality that appears operationally reasonable.
Agent ecosystems inherit all of those risks and add another one: natural-language instructions can manipulate a reasoning system without introducing conventional malware.
The correct security objective is therefore not to ensure that no malicious skill ever enters the environment.
It is to ensure that a malicious skill cannot convert instructional influence into unrestricted enterprise authority.
For a financial institution, that means provenance before admission, adversarial verification before promotion, graduated trust before privilege, deterministic enforcement before tool execution and behavioural evidence after consequential actions.
It also leads to a principle that agent platforms will eventually need to encode directly:
No skill should automatically inherit the full authority of the agent that reads it.
The same principle applies to MCP servers, workflow templates, agent-to-agent delegations and marketplace-distributed autonomous capabilities.
We spent decades learning not to execute arbitrary code simply because someone packaged it conveniently.
The agentic era should not require us to learn the same lesson again simply because the executable dependency happens to be written in English.
Source: r/GenAI360 · by /u/Aware_Weight9462