Notifications
Clear all
Topic starter
18/08/2026 2:50 pm
TL;DR: Static skill scans miss external-doc backdoors in agentic AI because the real risk emerges at runtime, when an agent decides whether to trust, execute, or combine skills and tools, according to Ory. The governance gap is that authorization has to follow agent behaviour, not just inspect code or prompts.
NHIMG editorial — based on content published by Ory: From Static Skill Scans to Runtime Agent Control: How Ory Agent Security Addresses the “Story of Skills” Threat
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern agent skills that can be loaded from external sources?
A: Treat externally loaded skills as privileged inputs, not ordinary content.
Q: Why do static scans fail to stop malicious agent behaviour?
A: Static scans only inspect what was written or attached, not how an agent will interpret and combine it during execution.
Q: What breaks when AI agents can chain skills without fresh approval?
A: The boundary between intended and unintended action collapses.
Practitioner guidance
- Map agent trust boundaries to runtime policy enforcement Identify every point where an agent can accept external skills, documents, or instructions and require authorization before execution.
- Scope permissions to a single agent session Remove standing access where the agent can reach data sources or tools beyond the current task.
- Classify external skills as privileged inputs Subject skill libraries, prompt packs, and external documents to the same change control, provenance review, and approval logic used for sensitive integrations.
What's in the full article
Ory's full blog covers the operational detail this post intentionally leaves for the source:
- How Ory models runtime agent authorization and skill trust decisions in practice
- The specific agent security controls used to replace static scanning with execution-time policy checks
- Examples of external-doc and malicious-skill abuse patterns that practitioners can map to their own environment
- Implementation detail on how agent IAM, permissions, and session control fit together
👉 Read Ory's analysis of runtime agent control for malicious skills →
Agent skill backdoors and runtime control: are your policies ready?
Explore further
18/08/2026 3:32 pm
Static skill validation is not enough once the identity can decide at runtime. The article exposes a control gap that many agent programmes still miss: artefact review cannot govern live trust decisions. When a system can choose, combine, or sequence skills during execution, the security question shifts from code quality to runtime authorization. Practitioners should stop treating agent safety as a deployment-time problem and start treating it as an identity control problem.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Should organisations re-evaluate IAM and PAM for agentic AI deployments?
A: Yes, because agentic systems can inherit credentials and exercise privileged tools in ways that traditional IAM and PAM reviews do not fully capture. Organisations should reassess whether their current models account for ephemeral tasks, delegated authority, and machine-speed execution. The key test is whether access can be constrained to the exact task and revoked immediately afterward.
👉 Read our full editorial: Runtime agent control for skill backdoors in agentic AI
