Treat documents, templates, and skills as trusted inputs that need policy checks before they enter the agent context. Teams should restrict which artifacts can influence the system prompt, limit what fields can be changed, and retain evidence for every runtime decision.
When agentic AI is shaped by documents and skills, what is really being governed?
Teams are not just governing model output. They are governing the inputs and runtime artifacts that can alter what an agent sees, how it reasons, and what it is allowed to do. That means documents, templates, and skills need explicit trust boundaries, policy checks, and change control before they can influence the agent context.
The practical question is whether an artifact is merely content or whether it can change behaviour. Once a document, template, or skill can steer prompt construction, tool selection, or action sequencing, it becomes a governed control point, not a passive file.
How to treat documents and skills as governed inputs
Documents and skills should be handled as policy-mediated artifacts with a clear approval path. The safest model is to allow only known, scoped sources to enter the agent context, and to limit which fields, instructions, and parameters those sources can modify.
That usually means separating content from control. A document can supply facts, but it should not be able to silently redefine role, scope, tool access, or escalation rules. A skill can provide reusable behaviour, but it should be versioned, reviewed, and constrained by the permissions of the calling workflow.
For teams building agent pipelines, the useful design question is whether an artifact is allowed to influence planning, execution, or both. If it affects planning, it needs tighter policy. If it can affect execution, it needs stronger authorization, logging, and rollback assumptions.
What governance has to cover at runtime
Runtime governance is about preventing uncontrolled influence from becoming uncontrolled action. That is why teams should validate what enters the agent context, constrain what can be rewritten, and record what the agent actually used when it made a decision.
In practice, evidence matters as much as policy. Teams should be able to show which artifact versions were loaded, which checks passed or failed, which fields were accepted, and which runtime decision was made as a result. That evidence is what makes later review, incident analysis, and accountability possible.
Tools and skills also need to be treated as a chain of trust. If one skill can invoke another, or if a document can trigger a template that changes downstream behaviour, the governance model should assume the entire chain can be influenced unless each hop is independently checked and logged.
Risk and Threat Considerations
Document-driven agents and skill-driven workflows expand the attack surface because the attacker does not always need direct model compromise. A poisoned template, a malicious skill package, or an overpermissive context source can steer behaviour while still looking like normal operational input.
Failure mechanism: Untrusted or weakly governed artifacts alter the agent context, change tool selection, or inject instructions that the system treats as authoritative. If the platform does not enforce policy at artifact ingress and at action time, the agent can be manipulated into unsafe, unauthorized, or high-blast-radius behaviour.
Impact: The result can be privilege abuse, bad decisions, unsafe automation, data exposure, or chains of actions that are difficult to attribute after the fact. In larger environments, the same weakness can spread through shared templates or reusable skills and create correlated failures across many agent workflows.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agent behavior changes driven by trusted inputs and delegated authority. |
| ASI02 — Tool Misuse | Documents and skills can steer agents into unsafe tool selection and execution. | |
| ASI06 — Memory & Context Poisoning | The question is about artifacts influencing agent context and downstream behaviour. | |
| Recommendation — Enforce per-action policy checks to stop artifacts from expanding agent privilege. Restrict which inputs may trigger tools and validate tool-use decisions at runtime. Filter and version context inputs so untrusted artifacts cannot poison agent behavior. | ||
| CSA MAESTRO | GOVERN — GOVERN | Applies to governance of agentic AI artifacts, approvals, accountability, and oversight. |
| Recommendation — Define approval, ownership, and evidence requirements for agent-influencing artifacts. | ||
| NIST AI RMF | GOVERN — GOVERN | Supports governance and accountability for AI system inputs and runtime decisions. |
| Recommendation — Establish policy, oversight, and documentation for agent-influencing inputs. | ||
Practitioner Guidance
What to prioritise: Start with the artifacts that can change behaviour, not the ones that only change wording. Templates, instruction bundles, and skills that influence prompts or tool calls deserve the strongest review and the narrowest write permissions.
What to verify: Confirm that the agent can only consume approved artifact versions, that mutable fields are explicitly limited, and that every runtime decision leaves an audit trail linking the decision back to the exact input set used.
Common mistake: Teams often secure the model endpoint but leave the surrounding content pipeline wide open. If influence can be injected before the model ever runs, endpoint hardening alone will not control the behaviour of the system.
Practitioner takeaway: Treat influence as a governed capability, not a side effect, and make every artifact that can shape agent behaviour pass the same kind of scrutiny you would apply to a privileged change in production.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern agentic AI access to secrets without losing visibility into runtime behaviour?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?