Runtime agent control for skill backdoors in agentic AI

At a glance

What this is: This is an Ory analysis of why static skill scanning is insufficient for agentic AI and why runtime authorisation is the control point that matters.

Why it matters: It matters because IAM, PAM, and AI governance teams need controls that evaluate agent actions as they happen, not just before deployment or during code review.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Ory's analysis of runtime agent control for malicious skills

Context

Agentic AI changes the trust model because the system does not just execute a fixed workflow, it decides which skills, tools, and data sources to use at runtime. In that model, a static preflight scan can tell you what was shipped, but not whether an external document, prompt, or skill library will be used maliciously once the agent is live.

For identity teams, the issue is not simply model safety. It is runtime authorisation for non-human identities that can select actions dynamically, which pulls the problem squarely into NHI governance, access control, and delegated privilege management. The article's premise is that malicious skills are a control bypass problem, not just a content review problem.

This is a typical problem for early-stage agentic AI programmes: teams assume that scanning the artefacts around an agent is enough, when the actual exposure appears in execution-time trust decisions.

Key questions

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. Security teams should require provenance checks, approval gates, and runtime authorization before an agent can execute them. The key is to control what the agent may trust at the moment of use, because static review alone does not prevent malicious instructions from becoming active inside a live session.

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. Once an agent can select tools and act with delegated permissions, the security problem becomes contextual and session-based. That means the decisive control is runtime policy enforcement, not only code or prompt inspection.

Q: What breaks when AI agents can chain skills without fresh approval?

A: The boundary between intended and unintended action collapses. A malicious or compromised skill can become executable mid-session if the agent is allowed to chain tools or re-use trust without revalidation. In practice, that turns delegated access into a flexible attack path and makes containment much harder.

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.

Technical breakdown

Why static skill scanning misses runtime agent behaviour

Static scanners inspect code, prompts, or attached documents before deployment. That is useful for finding obvious injection points, but it cannot determine how an agent will combine instructions, context, memory, and tools during a live session. In agentic AI, the dangerous decision is often not the presence of a skill itself, but when the system chooses to trust it, chain it, or execute it with elevated context. The control problem therefore sits at runtime authorization, not only at build time review.

Practical implication: treat predeployment scanning as a narrow control and add runtime decision enforcement for agent actions.

Agent authorization as the real control boundary

An AI agent is a non-human identity when it acts through tokens, service credentials, or delegated permissions. The trust boundary is crossed when the agent can independently select tools or skills and execute them against business systems. At that point, the question is not whether the code looked safe, but whether the session had enough authority to prevent a malicious or unexpected skill from being invoked. This is why authorization must evaluate context, intent, and allowed actions in the moment of use.

Practical implication: bind agent permissions to task scope and session context instead of granting broad standing access.

External-doc backdoors and malicious skills as identity abuse

External-document backdoors are a form of identity abuse in which a seemingly harmless file, page, or skill definition carries instructions that alter the agent's behaviour. The risk resembles supply-chain compromise, but the exploit path is identity-centric because the agent is the executor. Once the agent trusts the external input, it may retrieve data, call tools, or expose secrets outside the operator's intent. That makes the problem closer to delegated privilege misuse than to traditional content moderation.

Practical implication: govern external inputs as privileged execution artifacts, not as passive content.

Threat narrative

Attacker objective: The attacker wants the agent to execute malicious instructions using legitimate delegated access, turning trusted automation into an abuse path.

1. Entry occurs when a malicious external document, skill, or backdoor is introduced into the agent's trusted context. Credential access is not the first step here; the attacker is trying to shape the agent's runtime decision path before it acts.
2. Escalation happens when the agent accepts that input and uses its delegated permissions to select tools, retrieve data, or invoke workflows beyond the operator's intended scope. The misuse is enabled by over-trust in runtime context.
3. Impact follows when the agent performs unauthorized actions, leaks sensitive data, or executes destructive tool calls that the human operator did not directly approve.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime agent control is the correct boundary for agentic AI governance. Ory's framing aligns with the broader agentic security problem: the dangerous moment is not the existence of a skill but the moment an autonomous executor is allowed to trust and use it. That puts the issue inside NHI governance, ZTA thinking, and privilege scoping rather than generic application scanning. The practical conclusion is that agent sessions need explicit policy gates tied to context, not broad standing permissions.

Malicious skills behave like identity payloads, not ordinary content. The article's core lesson is that external-doc backdoors exploit delegated authority rather than software defects alone. This is where agentic AI differs from traditional automation: the attacker is targeting the decision layer of the executor, not merely the codebase. Security teams should therefore classify untrusted skills, documents, and tool definitions as privileged execution inputs and govern them accordingly.

Ephemeral trust debt is the right concept for this threat class. The longer an agent can carry ambient trust from one context to another, the more likely a malicious skill or instruction set becomes actionable. That debt accumulates when permissions outlive the specific task and when runtime state is not revalidated before tool use. For practitioners, the implication is clear: if trust is not re-scoped at execution time, the agent inherits too much authority for too long.

Agentic AI forces IAM and PAM to converge at the session level. The article is really about who or what is allowed to act when the actor is non-human and decisions are not pre-scripted. Traditional IAM often assumes stable subject identity, while PAM assumes high-risk actions can be isolated to obvious elevation events. Agentic systems blur both assumptions, so the governance model has to unify identity, privilege, and tool authorization in one runtime policy layer.

From our research:

• 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.
• For runtime-focused controls, read OWASP NHI Top 10 for the agentic risk patterns that static review misses.

What this signals

Runtime authorisation is becoming the governing control for agentic systems. As soon as an AI system can decide which skill or tool to trust at execution time, the old split between application security and identity governance stops working. Programmes that still depend on static review will struggle to explain why a trusted session executed an untrusted action, especially as agent-to-tool delegation becomes more common.

Ephemeral trust debt: the longer an agent retains permissions across tasks, the more opportunity there is for malicious inputs to become actionable. That means lifecycle thinking has to extend into session scope and trust revalidation, not just onboarding and offboarding. Teams that already use NIST SP 800-207 Zero Trust Architecture will find the fit here is conceptual, not cosmetic.

The practical signal for security leaders is that agent controls should be measured by how often runtime policy blocks risky tool use, not by how many skills were scanned at build time. If your programme cannot answer that, it is not yet governing agent behaviour, only inspecting artefacts.

For practitioners

• 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. Treat those inputs as governed execution artifacts, not passive content.
• Scope permissions to a single agent session Remove standing access where the agent can reach data sources or tools beyond the current task. Revalidate access at each high-risk tool call so trust does not carry forward by default.
• 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.
• Add deny-by-default guardrails for tool chaining Block agents from chaining skills or invoking downstream tools unless the specific sequence has been approved for that use case. Review any capability that lets an agent combine steps without fresh policy checks.

Key takeaways

• Agentic AI changes the security question from what was scanned to what was authorised at runtime.
• Malicious skills and external-doc backdoors are identity abuse patterns because they target delegated execution, not just software quality.
• Security teams need session-scoped authorization, deny-by-default tool chaining, and provenance checks for external inputs before agentic controls can be trusted.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• External-doc backdoor: An external-doc backdoor is a malicious instruction hidden in a document, page, or skill artifact that changes an agent's behaviour when it is trusted at runtime. The risk is not the file itself, but the delegated authority that lets the agent treat the content as executable guidance.
• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent — covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.

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

👉 Ory's full post covers the threat pattern, runtime control model, and implementation context in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.