Research · Working paper · Public edition
Agent capabilities leak through the software supply chain
Committed samples, metadata, and coding-agent settings hand the next org a grant the author treated as demo scaffolding.
This is the public edition of a working paper (October 2026). Case details are withheld pending coordinated disclosure. Every example on this page describes a generic risk pattern, not a specific repository, and no credential was used or tested.
Thesis
Clone is install. Install is the grant.
An agent is a policy over tools, data, and identity. A repository is a distribution channel for that policy. Clone is install. Install is the grant. The failure mode is not a clever jailbreak. The failure mode is a sample that already contains the grant, shipped as the blessed way to build the agent.
First principles
- A tool with an effect is a capability, whether or not the prompt is polite.
- A model-supplied argument is untrusted input. Amount, contact, record id, email, and file id are untrusted when the model fills them.
- A confirmation the model can set is not a confirmation. A deny list beside an allow-all is not a boundary.
- Sharing, run mode, and guest exposure are part of the tool, not an admin detail beside it.
- A secret in grounding config is two bugs. It is a credential. It is also a write path into data the agent trusts, which makes it an indirect prompt-injection channel into every org that deploys the kit.
Taxonomy
Twelve classes of risk that travel with a repository. Each one arrives the moment someone clones, deploys, or opens the project, because the grant is written into the files rather than configured afterwards.
| Class | What travels on clone or visit |
|---|---|
| C1Grounding credential | A cloud or API key committed in a data kit, grounding config, or metadata record that any user in the org can read. |
| C2Guest token mint | A guest-callable endpoint that returns an integration identity's credentials to an anonymous browser, so any visitor can act as the identity the agent runs as. |
| C3Coding-agent bypass | Committed coding-agent settings that pre-approve shell, file write, and network fetch, so the agent runs commands without asking. |
| C4Excessive agency | An action that moves money, places an order, or sends email, with the target chosen by the model and no human confirmation. |
| C5Model-chosen id | A read or page that ignores sharing and takes its record id from the model or the URL. |
| C6Identity bind | An agent-issued link that binds whoever opens it to a session they did not start. |
| C7Exfiltration pair | Two actions that look harmless alone, such as creating a public file link and drafting an outbound message, available in the same topic. |
| C8Instruction override | Topic or instruction text that tells the agent to drop its standard actions and guidelines, shipped as part of the code. |
| C9MCP grant-all | An editor MCP config that launches a server with every toolset enabled from an unpinned package, the moment the project is opened. |
| C10Prompt-layer gate | A confirmation or validation flag held in a variable the model can set. |
| C11Admin invocable | An invocable that runs a caller-supplied query, unlock, or upsert in system mode, later wired up as an agent tool. |
| C12OAuth without state | An account-link flow that accepts an attacker-chosen id and sends no state parameter. |
Why file scanners stop
A flow scanner can see system mode. A secret scanner can see a PEM-shaped key in a source file. Neither has the edge the agent adds: which topic may call the action, whether the caller is a guest, whether the argument is model-controlled, and whether confirmation is a human act or a variable.
A public chat action calls a system-mode flow that creates an order for a model-chosen contact, with confirmation off. Looked at file by file, the inner node is a flow smell. The incident is the edge: an anonymous visitor can ask the agent to place an order on someone else's account.
An editor config starts an MCP server with every toolset. A scanner that cannot read that config shape cannot see the grant. That is a parser gap, not a model-quality gap.
One action creates a public internet link for a file the user can see, with confirmation off. The same topic can draft email. A prompt injection planted in a record or a knowledge article can publish the file and draft the send. Neither action looks like an incident on its own.
These chains are composites written to explain the mechanism. They are not descriptions of any named or identifiable project.
What this does not mean
It does not mean a general code scanner is useless. It means the agent edge is a second pass. Run your platform vendor's code scanner, and run an agent-aware pass that joins action, flow, run mode, and effect. One complements the other; neither replaces it.
What to change
If you publish samples
- Ship credentials through named or external credentials. Never commit a data-kit key.
- Guest controllers do not mint integration tokens.
- Money, order, and email actions require a human confirmation and a server-side check of the target.
- Agent actions run with sharing. Guest agents do not get system-mode writes.
- Review topic and instruction text like code.
- MCP configs pin a version and list only the toolsets the sample needs.
- Coding-agent settings in a sample do not pre-approve shell.
If your enterprise clones samples
- Treat a vendor sample as untrusted code plus untrusted policy.
- Before you deploy, search metadata for key material, search agent actions for confirmation turned off on a write, search flows for system mode reached from a guest topic, and search editor and coding-agent settings for allow-all.
- Rotate anything that arrived in the clone. Do not test keys you find.
If you build scanners
- Join the edge: action to flow to run mode to effect to exposure.
- Parse editor MCP config and coding-agent settings as policy, not as data.
- Analyze topic and instruction text as code.
- Keep a public miss list. A session-binding miss and an OAuth-state miss belong in the write-up, or the hits read as selected.
Reader check
No tool required. Search your own trees, especially any sample you are about to open in an editor or a coding agent, for:
bypassPermissionsBash(*)approval_policyset toneverdanger-full-accessapprovalModeset tounrestricted- An MCP launch with every toolset enabled, or an unpinned
latesttag
# Coding-agent settings that skip approval
grep -rnE --include='*.json' --include='*.toml' --include='*.yaml' --include='*.yml' \
'bypassPermissions|Bash\(\*\)|approval_policy[^,]*never|danger-full-access|approvalMode[^,]*unrestricted' .
# MCP launches that enable every toolset or float on an unpinned latest tag
grep -rnE --include='*.json' --include='*.toml' --include='*.yaml' --include='*.yml' \
-e '@latest' -e '--toolsets?[" ,=]+"?all' -e 'TOOLSETS"?[ :=]+"?all' .A hit is not proof of compromise. It is a grant someone committed on purpose or by accident, and it deserves a review before anyone opens the project with an agent attached.
Limitations and known misses
Some of these classes are missed by current tools, including SquireX. Session binding (C6), OAuth without state (C12), and two-action exfiltration pairs (C7) need reasoning across actions, sessions, and redirects that today's file-level and agent-level scanners do not reliably do. We list them because an evaluation that only prints hits is an ad.
This edition makes no accuracy claims and publishes no benchmark numbers. Coverage for coding-agent settings (C3) is new work in SquireX and has not yet been measured, so this paper describes the pattern and does not claim detection.
Case details are withheld until the affected maintainers have been notified privately and have had time to respond.
What SquireX does
SquireX is an agent-aware scanner for Agentforce, ServiceNow, MuleSoft, and MCP. It joins agent actions to the flows, run mode, and exposure behind them, and we are adding coverage for coding-agent settings. Run it alongside your platform vendor's code scanner.