Join our Newsletter — 33% off our NHI Course

How should teams govern AI tools that can be instructed by repository files or extensions?

Treat agent instructions and extension privileges as part of the trusted computing base. Separate human-facing content from agent-facing control files, limit which extensions can invoke AI tools, and require monitoring for secret collection patterns. The governance question is who can redirect the agent, not just who can install it.

Repository instructions and extensions change the trust boundary

When an AI tool can read repository files, prompt files, or extension-delivered instructions, governance has to treat those inputs as part of the tool’s operating surface, not as ordinary content. That means the main question is which files and extensions are allowed to influence tool behaviour, under what review, and with what logging. Teams should assume that instruction channels can be manipulated as easily as code.

The practical distinction is between human-authored project content and agent-facing control material. A README can explain a project to people, but a prompt file, policy file, or extension configuration can also steer an agent’s actions. For that reason, teams need explicit boundaries for what the agent is permitted to interpret as control, and they should treat poisoned repository instructions as an execution path rather than a documentation problem.

Extension privileges deserve the same treatment. If an extension can invoke the AI tool, read local secrets, or modify prompts, it becomes part of the trusted computing base for that workflow. Governance should therefore focus on the smallest set of extensions and repositories that are allowed to shape agent behaviour, with the same care used for privileged automation.

What good governance looks like in practice

Good governance starts by limiting who can redirect the agent and what they can redirect it toward. In practice, that means separating human-facing content from agent-facing control files, constraining extension permissions, and making the allowed instruction sources explicit. It is better to manage a narrow, named set of control paths than to allow any repository file to become implicit policy.

That separation also improves review quality. Teams can review agent instructions as operational controls, not as prose, and can apply stricter change control to files that can alter tool selection, output scope, or access to external systems. Where extensions can trigger AI actions, AI agent identity and security controls should include permission scoping, approval rules, and clear ownership for each capability.

Monitoring must cover both direct misuse and slow-burn manipulation. Secret-collection patterns, unexpected outbound requests, unusual file reads, and hidden prompt fragments are all signals that the instruction surface is being abused. The governance model should not rely on the assumption that agents will only follow obvious user commands.

Why this becomes a supply-chain and privilege problem

Once an AI tool can be steered by repository files or extensions, the risk is no longer just bad output. The same path can be used to harvest secrets, trigger unauthorized actions, or redirect the agent into unsafe tool calls. A compromised extension or repository instruction file can therefore create a supply-chain style compromise of the agent workflow.

Teams should also expect misuse to scale quickly when the same instruction source is shared across many projects or environments. A malicious or overbroad extension can turn one weak trust decision into repeated exposure across multiple developers, agents, or repositories. That is why the governance question is not simply whether the tool works, but whether the control surface is bounded enough to withstand hostile inputs and extension-driven secret exposure.

When the agent has access to production credentials, the blast radius rises from workflow disruption to real environment impact. In that case, instruction integrity, extension allowlisting, and secret-scanning telemetry are not optional hardening steps, they are core controls for preserving trust in the automation path.

Risk and Threat Considerations

Repository files and extensions can be used to smuggle instructions into a trusted agent path, especially when the tool automatically reads local context or loads third-party add-ons. The result is a control-plane attack on the agent itself, where a seemingly ordinary file or extension changes what the tool does, what it reads, or where it sends data.

Failure mechanism: An attacker or careless contributor places instruction content in a file the agent trusts, or ships an extension with broader privileges than intended. The agent then follows hidden directives, invokes unsafe tools, or exposes secrets through normal-looking actions.

Impact: The likely outcome is unauthorized access, data leakage, destructive actions, or repeated compromise across every environment that trusts the same instruction source or extension path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 ASI03 — Identity & Privilege Abuse Agent instructions and extension privileges can redirect tool authority.
Recommendation — Restrict agent and extension authority to prevent instruction-driven privilege abuse.
OWASP Non-Human Identity Top 10 NHI-02 — Secret Leakage Repository instructions and extensions can expose secrets through agent actions.
NHI-05 — Overprivileged NHI Extensions that can invoke tools or read secrets need tight privilege boundaries.
NHI-10 — Human Use of NHI Governance must separate human-facing content from agent-facing control files.
Recommendation — Scan instruction sources and extensions for secret leakage paths before trust is granted. Constrain extension permissions to the minimum needed for each approved workflow. Separate human-authored content from machine-controlled instruction files.
NIST AI RMF Govern This is an AI governance question about control, accountability and oversight.
Recommendation — Define ownership and oversight for every agent instruction source and extension.
ISO/IEC 42001:2023 AI management system AI system governance needs documented controls over agent instructions and extensions.
Recommendation — Document, approve, and monitor the controls governing AI tool behavior.
NIST SP 800-53 Rev 5 AC-6 — Least Privilege Extension permissions and agent access should be minimized to reduce misuse.
Recommendation — Apply least privilege to every extension and agent action path.

Practitioner Guidance

What to prioritise: Classify every file and extension that can influence agent behaviour into trusted, reviewable, and untrusted categories. If a control file can change tool invocation, treat it like privileged configuration rather than project documentation.

What to verify: Confirm that the agent can only read instruction sources that are intentionally designated for machine use, and that extensions cannot silently expand their own permissions. Audit for the ability to read secrets, call external tools, or rewrite agent prompts.

Decision rule: If an extension can both influence instructions and access secrets, require explicit approval and logging before deployment. If it can only provide read-only context, keep it outside the control path and limit the data it can see.

Practitioner takeaway: The safest governance model is to reduce the number of things an agent is allowed to trust, then make every remaining trusted path observable and reviewable.