Teams should govern them as part of the agent attack surface because they can steer behaviour before any obvious tool call occurs. If instruction layers can change outcomes without generating clear logs, they need the same scrutiny as explicit permissions and connectors.
Skills and retrieved context as a governed agent control surface
Agent skills and retrieved context should be governed as operational inputs that can change what an agent does before any explicit tool invocation. Treat them as part of the control plane for behaviour, not just as content. If a skill can inherit permissions, pull in hidden instructions, or shape decisions without leaving a clear approval trail, it deserves access review, ownership, and change control.
That framing matters because the risk is not limited to a bad tool call. A skill pack, prompt bundle, retrieval source, or memory fragment can steer plan selection, alter scope, and widen exposure while still appearing “read only” to the operator. Good governance therefore asks who can publish, approve, update, and retire these artefacts, and what they are allowed to influence.
Teams should also classify retrieved context by trust level and provenance. Context that originates from user uploads, web retrieval, shared memory, or third-party sources should not be allowed to override policy, credentials, or explicit task boundaries unless that behavior is intentional and reviewable. In practice, the governance question is whether the agent is consuming context as data, or accepting it as instruction.
What needs policy, approval, and provenance
Skills need the same discipline as other high-impact runtime dependencies because they can bundle instructions, examples, and permissions into one package. A skill registry should make ownership visible, define who may publish or modify a skill, and require review for anything that can request secrets, invoke sensitive actions, or inherit ambient access.
Retrieved context needs similar treatment, but the control emphasis shifts to provenance, freshness, and scope. Retrieval sources should be tagged so teams can tell whether content came from an approved internal corpus, a transient session, or an external source. When context can be cached, reused, or shared across sessions, that reuse needs explicit limits, because stale or cross-scope context can silently change behavior.
For governed agents, the most useful question is not “did the agent call a dangerous tool?” but “what inputs were allowed to shape the decision that led there?” That is why policy should cover skill installation, skill updates, retrieval sources, memory boundaries, and any mechanism that can change the agent’s effective authority without a separate permission event. For teams standardising agent controls, the AI Agent Authorisation Guide is a useful companion for turning that principle into least-privilege decisions.
How to keep instruction layers observable and bounded
Skills and retrieved context become dangerous when they are powerful but indistinct. If an operator cannot tell whether a behavior change came from the base agent, a skill, a retrieval source, or a hidden instruction layer, then attribution and rollback will be weak. The governance model should therefore separate the source of the instruction from the action it influenced, even when the underlying UX tries to hide that complexity.
That also means teams should insist on traceability at the point where context enters the agent. A skill should be versioned like code, retrieval should be attributable like a dependency, and any instruction that can affect action should be reviewable before promotion. If your team cannot answer which skill, document, or memory item influenced a decision, you do not really have governance, only post hoc inspection.
In mature programmes, the same control set also supports incident response. If a skill or retrieved source is later found to be malicious or contaminated, teams need to revoke it quickly, isolate affected agents, and determine which runs consumed it. The AI Agent Observability, Audit and Incident Response Guide is directly relevant here because it focuses on attribution, logging, and kill-switch decisions when agent behavior needs to be contained.
Risk and Threat Considerations
Skills and retrieved context can be abused to create “quiet” compromise paths because they influence reasoning before a visible action occurs. That makes them attractive for instruction injection, hidden persistence, privilege expansion, and manipulation of downstream decisions, especially where retrieval sources or skill bundles are accepted with too much trust.
Failure mechanism: A malicious or overbroad skill, or a poisoned retrieval source, changes the agent’s behavior without triggering an obvious authorization step, so the operator sees only the later consequence.
Impact: The result can be unauthorized data exposure, unsafe tool selection, policy bypass, or actions that are difficult to explain, roll back, or attribute after the fact.
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 Agentic Skills Top 10 address the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Skills and retrieved context can alter agent authority and behavior. |
| ASI06 — Memory & Context Poisoning | Retrieved context can be poisoned or manipulated before tool use. | |
| Recommendation — Restrict skill and context inputs that can expand agent authority without review. Validate retrieval provenance and isolate untrusted context before it reaches the agent. | ||
| OWASP Agentic Skills Top 10 | AST10 — OWASP Agentic Skills Top 10 | Agent skills are the primary subject and need direct skill-layer governance. |
| Recommendation — Review skill registries, permissions, and inheritance before allowing production use. | ||
| NIST AI RMF | GOVERN — Govern | Governance is needed for ownership, policy, and accountability over agent inputs. |
| Recommendation — Define accountability, approvals, and oversight for skills and retrieved context. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Agent inputs need auditable records to support attribution and review. |
| Recommendation — Log skill changes and retrieval events that influence agent decisions. | ||
Practitioner Guidance
What to verify: Verify that every skill and retrieval source has an owner, a version, a trust label, and a defined approval path before it can influence production agents. If a component can shape plans or instructions, it should not be treated as informal content.
Decision rule: If the input can change agent behavior without a separate permission event, govern it like a control surface, not like documentation. If the input can also touch secrets, credentials, or delegated authority, require stronger review and tighter scope than you would for ordinary retrieval.
Practitioner takeaway: The right model is to govern agent skills and retrieved context as privileged behavioral inputs, because the security boundary is crossed when the agent accepts influence, not only when it executes a tool.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org