You approved an AI agent yesterday. Someone updated a skill, changed a tool or replaced a dependency overnight. What, exactly, is still covered by that approval?
The agent’s model may be unchanged while the system around it has become different. A trusted workflow can inherit new instructions, executable code, endpoints or permissions through components that receive much less attention than the model itself.
DN’s thesis: agent trust needs a record of who can change the system, what those changes can affect and which evidence must be renewed before authority expands.
What Matters
- Inventory more than software packages. Include skills, tool definitions, retrieved instruction sources and remote services.
- Distinguish identity from behaviour. A known publisher can still ship a defective or inappropriate update.
- Record update authority. Identify who can change each component and whether deployment requires review.
- Bind review to an observable state. Record versions, digests, configuration and review dates where available.
- Enforce authority outside the model. A skill’s text should not be able to grant itself financial permissions.
- Treat unknowns as unknowns. Missing evidence does not prove compromise, but it limits justified trust.
Evidence Block
Source review: 13 October 2026. This is an editorial framework, not a completed audit of listed products. DN has not measured attack prevalence or assigned vendor security rankings.
Anthropic describes Agent Skills as folders containing instructions, scripts and resources that agents can load for specialised work. Its guidance also discusses evaluating trust when using skills from external sources.[1]
MCP’s security documentation covers risks including local server compromise, token passthrough and excessive scopes. A functioning connection is therefore not sufficient evidence that the surrounding implementation is secure.[2]
OWASP identifies supply-chain exposure and excessive agency as distinct risks for LLM applications. DN connects them here through a practical question: what can an externally supplied component influence, and what authority remains independently enforced?[3] [4]
SLSA provenance describes evidence about how an artefact was produced. Provenance supports verification of origin and build history; it does not by itself establish that an agent’s behaviour is acceptable for a particular financial task.[5]
The Agent Supply Chain Has Several Kinds of Influence
Traditional software inventories remain useful. Agents also consume material whose influence depends on interpretation: instructions, tool descriptions, examples and retrieved content.
A package can execute code. A skill can shape how work is performed. A remote tool can return data or carry out an action. A retrieved document can contain text that the agent should treat as evidence rather than an authoritative instruction.
Those components deserve different controls. Treating every item as “trusted” or “untrusted” without describing its role leaves the actual boundary unclear.
| Component | Possible influence | Evidence to record |
|---|---|---|
| Model and runtime | Reasoning, execution environment and available interfaces. | Provider, version, configuration and change notices. |
| Skill or instruction bundle | Workflow guidance, scripts and resource loading. | Publisher, source, reviewed contents and release reference. |
| MCP server or connector | Tool catalogue, returned information and downstream actions. | Operator, endpoint, authentication, scopes and deployment controls. |
| Package or container | Executable behaviour and transitive dependencies. | Inventory, immutable references and applicable provenance evidence. |
| External document or feed | Information consumed by the agent. | Source, freshness and how content is separated from instructions. |
| Authority policy | Permitted actions, destinations and limits. | Policy owner, enforcement point and tested boundary behaviour. |
The Change Gap: Trusted Yesterday, Different Today
Consider a hypothetical research agent that uses a third-party skill to produce portfolio summaries. The original version reads local files. A later version adds a helper script and a new remote endpoint.
The change could be legitimate. It still alters the review question: which information can leave the environment, which code runs and who approved the new dependency?
The same issue arises when an unchanged client connects to a remote service whose implementation changes. Pinning the client’s package version does not freeze the server’s behaviour.
Record the distinction between components you can reproduce locally and services whose current state you depend on someone else to describe. For the latter, change notifications, contractual commitments, monitoring and limited authority may matter more than a local file hash.
A Signature Answers Only Part of the Question
A valid signature can establish that an artefact was signed by a particular key, assuming the verification and key binding are correct. It does not establish that the signer reviewed the behaviour you care about or that the signing key remains uncompromised.
A digest can identify bytes. It cannot explain whether those bytes send sensitive information to an inappropriate destination.
A provenance statement can improve traceability. Its usefulness depends on verification policy and the trust placed in the producer and build system. Keep origin evidence separate from behavioural testing and permission enforcement.
The operational question is cumulative: do you know where the component came from, what it contains, what it can reach and how changes will be handled?
Where the Financial Boundary Must Hold
A skill may suggest an action. The permission layer should determine whether that action is allowed. These are different responsibilities.
For a simulated payment workflow, test whether an instruction bundle can induce an action outside the approved destination list or spending limit. The expected result should be defined in advance and enforced by the execution system.
Do not rely on a natural-language instruction such as “never exceed this amount” as the sole control over a funded account. Likewise, approval should identify the relevant action and scope rather than grant vague permission for whatever a changed tool later requests.
These are proposed control tests. They do not establish legal compliance or readiness for live funds.
DN Dependency Review Planner
Review one dependency or deployment at a time. Select “Evidence recorded” only when you have a retrievable record relevant to the current configuration. The tool creates a review queue; it does not inspect systems or certify safety.
No URL scanning, package execution, credential access, external requests or input storage. Ordinary site analytics operate separately. “Evidence recorded” is your statement, not a DN verification.
The Dependency Register Behind the Planner
For each component, record its name, role, publisher or operator, source location, version or deployment reference, update owner, dependencies, data destinations, permitted actions, evidence links, review date and next review trigger.
Where a field is not applicable, explain why. A remote data feed may not have a local executable package, but its source identity and handling of returned content still matter.
Keep evidence specific. “Reviewed by engineering” is weaker than a link to the reviewed release, configuration, test results and named owner. Do not put credentials or sensitive account identifiers into a public register.
Review Changes by What They Can Affect
| Change | Review question | Possible evidence |
|---|---|---|
| New instruction text | Does it change objectives, escalation or tool selection? | Reviewed diff and representative task results. |
| New executable dependency | What code runs and what resources can it reach? | Dependency inventory and applicable integrity checks. |
| New endpoint | What data leaves, and who operates the destination? | Data-flow review and network policy. |
| Broader permissions | Is the added authority necessary for the task? | Scope justification and negative boundary tests. |
| Publisher or ownership transfer | Who now controls future releases? | Verified ownership record and renewed review. |
A cosmetic correction and a new payment capability should not receive identical treatment. Define material-change triggers so review effort follows plausible consequences.
The Economics of a Shared Dependency
Many apparently different agents can use the same package, skill repository, model endpoint or connector. A problem in that shared component can create correlated disruption across workflows.
This is a conditional risk mechanism, not a measured claim about current incident frequency. The business implication is that listing several vendors does not establish independence if their critical dependencies overlap.
Map important shared components and ask how work continues when one is unavailable or no longer trusted. A backup route is useful only if its access, data and operating procedure have been tested.
The Signal
Watch for deployments that can identify their current dependency state, explain material changes and renew relevant evidence without manually reconstructing the whole system.
DN Alpha Thesis
As agent capabilities become easier to assemble, maintaining justified trust across updates could become a valuable service. The commercial opportunity may lie in change visibility, authority controls and evidence management as much as component discovery.
This is a hypothesis, not a forecast of vendor winners. It weakens if existing software tooling handles these needs cheaply, if agents remain narrowly permissioned or if customers do not value the additional evidence.
Methodology and Limits
The DN planner applies a fixed editorial checklist. It reports known gaps before unknowns, retains all eight fields and avoids combining them into a safety percentage. The order is a reading aid, not a quantified severity ranking.
It cannot verify a publisher, review source code, validate a signature, discover transitive dependencies or determine whether a control actually works. Eight recorded answers are not proof of safety; evidence can be stale, incomplete or wrong.
To test the framework’s usefulness, compare whether maintaining this register improves time to identify affected deployments after a material change, reduces undocumented permission expansion or makes incident reconstruction faster. If it adds administrative work without those benefits, simplify the register and revise the thesis.
Security review remains a deployment-specific activity. This article supplies questions and evidence structure, not a substitute for implementation testing.
Continue Through the DN Toolkit
- MCP Reliability Guide: connection behaviour, failure handling and operational evidence.
- DN Agent Trust Dataset: authority and financial-control evidence.
- Agentic Tools Hub: discover resources with clear evidence boundaries.
- DN Dictionary: understand MCP, delegation, least privilege and prompt injection.
Sources
- Anthropic: Equipping agents for the real world with Agent Skills.
- Model Context Protocol: Security Best Practices, versioned documentation.
- OWASP Gen AI Security Project: LLM03:2025 Supply Chain.
- OWASP Gen AI Security Project: LLM06:2025 Excessive Agency.
- SLSA v1.2: Provenance. A software provenance reference, not an agent safety certificate.
Frequently Asked Questions
What is an AI agent supply chain?
It is the set of models, runtimes, skills, packages, tools, services and information sources that contribute to an agent’s operation.
Is an Agent Skill only a prompt?
No. A skill can include instructions, scripts and other resources. Review the actual contents and execution context.
Does an MCP connection prove a server is safe?
No. Connectivity does not establish secure authentication, appropriate permissions or trustworthy implementation.
Does a valid signature guarantee acceptable behaviour?
No. Signing evidence and behavioural suitability answer different questions.
Does version pinning freeze a remote service?
No. Pinning a local client does not necessarily freeze the remote implementation or returned information.
Should every update receive the same review?
No. Define material-change triggers based on what the change can affect, including code, destinations, permissions and authority.
Does the DN tool inspect dependencies?
No. It organises self-reported evidence statuses into a review queue.
Are all recorded answers a security certification?
No. Recorded evidence can be incomplete or stale, and the checklist is not a complete security audit.
Can the register contain credentials?
Keep credentials and sensitive account identifiers out of public registers. Use protected evidence references where appropriate.
Disclosure: DN’s register and planner are editorial frameworks. No measured vendor ranking, attack-frequency estimate, certification or investment recommendation is presented.
Related reading:
Your AI Agent Worked Once. Can It Do It Again?
The Cost of Human Rescue: The Labour Bill Hidden Inside AI Automation
Model Intelligence vs Harness Intelligence: Why AI Agents Fail
We Tested Five AI Finance Systems. Here Is What the Evidence Actually Proves.
Who Gets Paid When Two AI Agents Disagree?
The DN Agent Credit Score: Measuring Whether Autonomous AI Can Repay
About the Author
