Only if they can validate and govern those caches as executable content. Agent skills are often trusted too quickly, so the safer default is to reject bundled bytecode, rebuild from source at deployment, and apply the same integrity rules to skills that you would apply to any other software supply artefact.
Why runtime caches change the trust model for AI agent skills
Runtime caches inside an agent skill bundle are not just performance optimisations. They can become executable or semi-executable state, especially when the agent reuses cached prompts, plans, tool selections, credentials, or compiled artefacts across sessions. That makes the bundle harder to reason about, because the skill is no longer a static unit you can inspect once and trust forever.
For that reason, organisations should treat bundled cache content as part of the software delivery surface, not as disposable runtime residue. If the cache can influence behaviour, tool calls, or downstream execution, it belongs in the same integrity, provenance, and change-control model as the skill itself. This is the point where supply-chain discipline matters more than convenience.
That is also why a safer default is to rebuild from source at deployment rather than ship pre-populated runtime state. Reproducible build and packaging discipline reduces the chance that a hidden cache entry silently changes the behaviour of the agent after review. Where skills are delivered with cached state, the organisation should be able to explain exactly what the cache contains, who produced it, and how it is invalidated.
When a cache is acceptable and when it is not
Acceptance should depend on whether the cache is purely transient data or whether it can alter code paths, policy decisions, or authorisation boundaries. A harmless memoisation layer is one thing. A cache that stores executable instructions, tool routing decisions, embedded secrets, or previously authorised actions is much closer to a software artefact and should be governed accordingly.
In practice, the decision turns on four questions: can the cache be regenerated deterministically, can it be validated before use, can it be isolated from the skill’s trusted execution path, and can it be expired or revoked without breaking the control plane? If the answer to any of those is no, the cache is too risky to bundle by default.
Organisations also need to distinguish between local performance caches and shared caches. Shared or portable caches create replay risk, cross-environment contamination, and unintended reuse of state across tenants or projects. That is especially important when the skill can invoke tools or act on behalf of a user, because cached state can become a hidden privilege amplifier.
How to govern runtime caches without undermining the agent
The right control model is to treat caches as governed artefacts with explicit ownership, provenance, and expiry rules. If a cache is retained, it should be signed or otherwise integrity-checked, constrained to the narrowest possible scope, and tied to a versioned skill package so that the runtime can detect drift. If those controls are not practical, the cache should not be bundled.
Organisations should also place particular attention on anything that looks like precomputed permissions, secrets, or token material. Even when cached state was created legitimately, its value decays quickly, and stale entries can become an access problem as soon as roles, policies, or endpoints change. The safest posture is to force regeneration when trust conditions change rather than hoping the old cache still reflects reality.
For agentic systems, this governance problem is not abstract. AI Agent Authorisation Guide is useful here because it frames the core control question correctly, per-action authority is more important than bundled convenience. A cache that can bypass fresh authorisation checks should be treated as a control weakness, not a performance feature.
Risk and Threat Considerations
Bundled runtime caches can create a stealthy trust boundary problem: defenders review the skill package, but the cache quietly changes what the skill can do after deployment. That becomes dangerous when cached state carries instructions, tool context, or anything that can be reused across sessions, because compromise or misuse can persist beyond the original review point.
Failure mechanism: An attacker, compromised build pipeline, or overly trusted developer process can seed the cache with behaviour-changing content, then rely on the agent to execute or reuse it as if it were benign runtime state.
Impact: The result can be unauthorised tool use, unexpected actions, policy bypass, stale decisions, or lateral movement through whatever systems the skill can reach. The more privileged the agent, the more damaging a cached artefact becomes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, SLSA and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Cached skill bundles may retain secrets or token material that alters agent behaviour and access. |
| NHI-05 — Overprivileged NHI | Precomputed cache state can preserve excessive authority across agent runs and environments. | |
| NHI-07 — Long-Lived Secrets | Persistent runtime caches can extend the life of sensitive material beyond its safe trust window. | |
| Recommendation — Keep secrets out of bundled caches and rotate any exposed credential material immediately. Reduce cached authority to the minimum scope needed for each agent action. Expire or regenerate cached secret-bearing artefacts instead of reusing them indefinitely. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | A cache that changes agent behaviour can bypass fresh authorisation and expand effective privilege. |
| ASI02 — Tool Misuse | Cached instructions or tool routes can steer an agent into unsafe or unintended tool use. | |
| Recommendation — Require per-action authorisation for any agent behaviour influenced by cached state. Validate cached tool selections and block unreviewed tool invocation paths. | ||
| SLSA | Software Supply Chain Integrity | Bundled caches behave like delivery artefacts and need provenance and reproducible build discipline. |
| Recommendation — Rebuild deliverables from trusted sources and verify artefact provenance before deployment. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Runtime caches in bundles change deployed behaviour and should be governed as controlled configuration. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checks are needed when cached content can affect execution or decisions. | |
| AC-6 — Least Privilege | Cached state can preserve excess authority, so privilege must stay narrowly bounded. | |
| Recommendation — Subject cache-bearing bundles to formal change review before release. Verify cache integrity before execution and reject tampered artefacts. Limit cached permissions to the minimum required for the skill’s task. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Bundled caches are configuration-like components that need controlled changes and versioning. |
| Recommendation — Manage cache-bearing skill packages under formal configuration control. | ||
Practitioner Guidance
What to verify: Confirm whether each cached element is reproducible, integrity-protected, and safe to discard without changing the skill’s security posture. If you cannot validate the cache independently, do not let it ship as trusted content.
Decision rule: If the cached content can influence execution, tool selection, or access decisions, require the same review standard you would apply to code or configuration. If it is only a local performance optimisation with no security effect, keep it ephemeral and tightly scoped.
Common mistake: Teams often assume that anything inside a package has already been reviewed. In agent systems, that assumption breaks down quickly, because cached state can outlive the review that approved the underlying skill.
Practitioner takeaway: The safest operating model is to minimise trust in bundled state, rebuild what you can, and treat any cache that changes behaviour as governed software rather than convenience data.
Related resources from NHI Mgmt Group
- What do organisations get wrong about AI agent runtime control?
- How can organisations reduce AI agent runtime risk without stopping adoption?
- Should organisations allow AI skills to ship with compiled caches?
- When should organisations choose a broader AI runtime control plane instead of a single vendor agent platform?