Trusted Skills: The Authorization Blindspot

Executive Summary

An AI agent skill that was clean when you installed it can flip adversarial without a software update, a new deployment, or any change to the artifact your scanner evaluated. All that is required is a change to what the skill's referenced URL delivers at runtime. This is not a theoretical edge case. In June 2026, security researchers at AIR demonstrated it in production: a skill called brand-landingpage passed Cisco's scanner, NVIDIA's scanner, and skills.sh. It reached roughly 26,000 agents. Then the researchers replaced the content at the documentation URL the skill referenced, and demonstrated payload delivery to every one of those installed agents.

The mechanism is well understood in other security contexts. It is Time-of-Check to Time-of-Use: the skill was evaluated at registration, found clean, and issued a trust signal. The trust signal was consumed by enterprise security controls, developer tooling, and procurement processes. Months later, the skill's runtime behavior changed because the external content it fetched changed. The trust signal was not revoked. The scanners did not re-evaluate. The enterprise security stack had nothing to alert on.

This is the Trusted Skills problem, and it is the core of what we call the Authorization Blindspot: a class of authorized AI behaviors that operate within your approved toolchain while remaining invisible to traditional security controls. The skill is in the registry. The agent is credentialed. The business function is sanctioned. The data is moving to an endpoint you did not authorize.

This article explains the mechanics of the flip, why the browser extension supply chain attacks of 2017 through 2019 offer the closest practitioner parallel, and what security architecture changes are necessary before AI agent deployments scale past the point where the attack surface is manageable.

The Trusted Skills Problem

When a security team approves an AI agent skill for enterprise use, they are making a trust decision about a state. The skill exists at a specific point in time. Its manifest points at specific URLs. Its configuration references specific domains. The scanner evaluates those references, finds nothing malicious, and issues a trust badge. That badge then travels through the organization's supply chain: it appears in the skill registry, it satisfies the policy engine's allow-list check, it appears on the CISO's AI governance dashboard as an approved component.

What the trust badge does not capture is that the skill is not a fixed artifact. It is a dynamic software component with runtime dependencies on external resources. The content served at those URLs can change at any time, without any change to the skill manifest, without any change to the artifact that was scanned, without any change to the trust signal that was issued. The skill that your scanner approved and your policy engine trusts will, at the next agent invocation, fetch whatever those URLs are currently serving. That content goes directly into the agent's context window.

The flip is the moment when this property is exploited. A skill that was benign at registration time becomes adversarial because the content it fetches has been changed. The change can be a DNS update redirecting the skill's target domain to an attacker-controlled server. It can be a modification to the content hosted at the original URL. It can be a redirect rule change that returns different content based on request timing, user-agent, or source IP. The skill's manifest is identical to what was approved. The skill's registry entry is unchanged. The trust badge remains valid. The behavior has flipped.

The flip does not require a software update. It does not require pushing new code through any review channel. DNS TTL values are commonly 300 to 3,600 seconds. A redirect rule change takes seconds to propagate. An S3 bucket or CDN hosting a skill's reference content can have its contents replaced with a single API call. The time between a skill being flipped and every installed agent contacting the new endpoint can be measured in minutes.

This is a precise, documented, production-demonstrated attack. The AIR brand-landingpage research is the benchmark example. But the mechanism is not exotic, and the AIR team did not invent it. Any practitioner who worked through the browser extension supply chain compromises of 2017 through 2019 has seen this pattern before.

The Browser Extension Parallel

Between 2017 and 2019, a series of widely used browser extensions, each with hundreds of thousands or millions of installs, were compromised through a consistent structural pattern. A developer would build something genuinely useful: an ad blocker, a password helper, a productivity tool. Users would install it. Browser marketplaces would display it as reviewed and available. The trust decision was made. The extension was installed and marked trusted.

Over time, the developer would sell the extension to an acquiring party, have their developer account credentials stolen, or enter a partnership arrangement that modified the extension's behavior. In each case, the user's original trust decision remained intact and unreviewed. The extension was now doing something its initial review never assessed: injecting advertising, capturing form data submitted through the browser, exfiltrating browsing history, or serving as a beachhead for additional payload delivery.

The specific techniques varied across incidents. Some involved source code updates pushed through normal extension update channels. Others involved the extension's backend services, those external URLs the extension called at runtime, changing what they returned without any change to the client-side extension package itself. The common thread was that trust was established at a point in time and then consumed indefinitely without re-evaluation. The user never saw a prompt. The browser never flagged a change. The extension was doing something entirely different from the day it was installed, and the security model had no mechanism to surface that.

The AI agent skill ecosystem in 2025 and 2026 is replicating this pattern. The structural similarities are exact: trust is granted at installation based on a point-in-time evaluation, the granted trust signal persists without re-validation, and the artifact has runtime dependencies on external content that can be changed without modifying the artifact itself. An organization's AI governance stack running today resembles a browser circa 2016, before the major vendors tightened extension review, enhanced developer account security requirements, and introduced more granular permission models.

Two properties make the AI agent context more dangerous than the browser extension context was.

First, the flip in AI skills does not require an update push. The browser extension attacks that used the update channel at least required the extension store to process and propagate the change, creating a window for detection. A skill that fetches runtime content from an external URL can be flipped in minutes by a DNS change or a content modification at the source. There is no artifact to inspect. There is no update event to detect. The only observable is the runtime network call, and most organizations do not have runtime network monitoring instrumented for AI agent invocations.

Second, AI agent skills operate with agent-level permissions, not browser extension permissions. A browser extension has access to the tabs it is active in and the APIs it declared at install time. An AI agent skill operates within an agent context that may include read and write access to file systems, internal APIs, external communication services, memory stores, and function-calling capabilities that can initiate significant automated actions. The blast radius of a flipped AI skill is substantially larger than a compromised browser extension.

Browser extension supply chain attacks were a serious enough problem that browser vendors spent three to four years implementing structural responses. The AI agent skill ecosystem is at approximately the same developmental stage those extension ecosystems occupied in 2016, large enough to be a meaningful attack surface, immature enough that the equivalent governance infrastructure has not been built.

The AIR Experiment: A Documented Benchmark

In June 2026, security researchers at AIR conducted a controlled experiment to test whether current AI agent skill scanning infrastructure could detect and block a TOCTOU-based attack. They built brand-landingpage, pitched as a tool for building landing pages with Google's Stitch, and submitted it to the major AI agent skill registries.

One detail is worth stating precisely, because it is often reported loosely. The skill did not reference Google's legitimate stitch.withgoogle.com. It directed agents to documentation at stitch-design.ai — a lookalike domain the researchers controlled from the outset. The content hosted there at submission time was benign, and the scanners cleared it.

The scanning results were unambiguous. Cisco passed the skill. NVIDIA passed it. skills.sh listed it. Each scanner performed exactly as designed: it evaluated what was present at check time, found nothing malicious, and issued a trust signal.

The skill then accumulated installs through normal discovery channels. Developers, enterprise teams, and organizations deploying AI agents for brand-related work found brand-landingpage in the registry, saw its trust badges, and installed it. By the time AIR disclosed the research, the skill had 26,000 installs.

Once the install base was established, the researchers executed the flip. They did not need to hijack anything: they simply replaced the content on the domain they already owned, rewriting the fake documentation to instruct agents to download and run a script. Any agent invoking brand-landingpage after that rewrite would fetch the new instructions. In a production attack, that fetched content would include a prompt injection payload designed to manipulate the agent's subsequent behavior. Depending on the agent framework and its configuration, such a payload can redirect the agent to exfiltrate data, call unauthorized tools, modify its outputs, or serve as a relay for additional malicious instructions.

The scanners had no mechanism to detect the flip. The trust badges remained valid. Nothing in any organization's security stack, absent runtime network monitoring specifically configured for AI agent calls, raised an alert.

Three structural properties of the attack isolate the core design of the Trusted Skills problem:

The target is mutable after trust is established. The skill manifest did not change. The URL in the manifest did not change. The content served at that URL changed. Static scanners evaluate manifests and referenced URLs at registration time. They are not designed to monitor whether those URLs continue serving benign content throughout the skill's operational lifetime.

The trust signal propagates and persists. A skill that passes registry scanning is marked trusted. That marking travels through enterprise tooling, procurement workflows, and policy engines. It does not automatically expire or require re-validation when the skill's runtime behavior changes. Revocation requires someone to notice something is wrong, which is exactly what this attack class is designed to prevent.

The attack surface scales with install count and invocation frequency. Each of the 26,000 installs represents an agent that will contact the flipped endpoint every time it invokes the skill. In production deployments where an agent runs on a schedule or in response to user triggers, a single install can generate hundreds or thousands of adversarial fetch operations. The reach of the attack multiplies with operational frequency, not just raw install count.

The Authorization Blindspot

The brand-landingpage experiment is a specific, documented instance of a broader structural problem. We call it the Authorization Blindspot: the class of autonomous AI behaviors that operate entirely within an organization's authorized toolchain while remaining invisible to traditional security controls.

The Authorization Blindspot is not about unauthorized access. The agents generating these behaviors are credentialed. The skills they invoke are in the approved registry. The workflows they execute were reviewed and sanctioned. Every check that the organization's security infrastructure performs on authorization would return a pass. The blindspot is that authorization, as most organizations currently implement it for AI agents, is a grant of trust at a point in time. It does not validate ongoing behavior.

The mechanism by which this becomes a security failure follows a consistent pattern. An AI agent is deployed for a sanctioned business purpose. It is configured with credentials and permissions appropriate to that purpose. It uses skills from an approved registry. At runtime, those skills fetch external content to perform their function. If any of that external content has been flipped since the skills were approved, the agent will incorporate the flipped content into its context window and potentially act on it. Nothing in the authorization chain, the agent's credentials, the skill's trust badge, the policy engine's allow-list check, has any mechanism to detect this.

The authorization framework in most enterprise AI deployments is built around the question: "Was this approved?" The Authorization Blindspot exploits the fact that "was" is doing a lot of work in that question. The skill was approved when it was benign. The approval has not been revisited since then. The skill is now adversarial. The answer to "was this approved?" is still technically yes.

This is the conceptual shift that enterprise security teams need to make: approval is not a perpetual grant. It is a point-in-time assessment of a dynamic artifact with external dependencies. The artifact's behavior changes. The dependencies change. The approval must have a mechanism to change with them.

A second dimension of the blindspot involves how AI agent frameworks consume externally fetched content. In a traditional web application, content fetched from an external source is treated as untrusted data. It is parsed but not executed. It is displayed but not given authority. The web application security model, built over decades of hard experience with cross-site scripting and injection attacks, enforces a separation between trusted code and untrusted content.

AI agent frameworks do not consistently enforce this separation. When an agent fetches content from a configured URL and passes it into its context window, the content is processed by the same model that processes trusted instructions. The model does not have a reliable mechanism to distinguish between content that is authoritative, from the system prompt or operator configuration, and content that is merely fetched data. This is why prompt injection remains unsolved at the model layer: the architecture does not maintain a hard boundary between instruction and data.

The enterprise security implication is significant. The attack surface for an AI agent deployment includes not just the code running on your infrastructure, but every external resource that code will fetch from, for the entire operational lifetime of the deployment.

Authorized, and Invisible

It is worth separating this from a category it is routinely confused with. The Authorization Blindspot is not Shadow IT. Shadow IT is unauthorized systems. This is authorized systems doing things their operators cannot see. The defensive response to each is different: Shadow IT is countered by discovery and enforcement, this by runtime visibility and behavioral monitoring.

The pattern in enterprise AI deployments looks like this: a developer or operations team deploys an agent for a sanctioned function. The agent is approved and credentialed. It uses the organization's official AI platform. The CISO has signed off on the deployment category. At runtime, the agent fetches external content, calls third-party APIs, stores intermediate state in memory systems that may not be subject to data retention policies, and executes function calls that can read and write files, initiate external communications, or call additional services. A compromised skill makes some portion of this runtime behavior adversarial. Nothing in the security stack alerts, because the security stack is looking at authorization state, not runtime behavior.

Three properties make it distinct from conventional endpoint threats.

Authorized context provides cover. The agent's network traffic transits your perimeter controls as legitimate business traffic. A firewall that blocks unknown external connections does not block a whitelisted agent calling a whitelisted registry URL that has since been redirected. The authorization was granted to the URL, not to the current content at the URL.

Execution is distributed and asynchronous. AI agents run on schedules, respond to triggers, or execute as background processes. There is no user action corresponding to an agent invoking a compromised skill. The activity appears in logs as routine agent operations. Without behavioral baselines, there is nothing to distinguish legitimate invocations from compromised ones.

The blast radius scales with agent capability. The extent of damage possible from a compromised skill is proportional to the permissions granted to the agent. Agents with access to file systems, external APIs, or communication services create proportionally larger attack surfaces. Least-privilege discipline, well established for human users and service accounts, is frequently not applied to AI agents during initial deployment.

According to Gartner, at least 15 percent of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from zero in 2024. McKinsey's 2025 State of AI survey — 1,993 respondents across 105 nations — found 23 percent of organizations already scaling an agentic AI system in at least one business function, most of them in only one or two, and a further 39 percent experimenting.

Neither survey measures how many of those deployments load skills from public registries. What does not depend on the count is the structure: a skill that references an external URL inherits whatever that URL serves at the moment of invocation, and runtime monitoring able to detect that change is still nascent tooling.

The window between broad AI agent deployment and adequate runtime security tooling is where these attacks will operate. The brand-landingpage exploit operated inside that window. It will not be the last.

Strategic Defenses for the Enterprise

The following recommendations can be implemented with existing capabilities and do not require waiting for the AI agent security ecosystem to mature. They address the specific properties of the Trusted Skills attack pattern and the broader Authorization Blindspot.

1. Treat Skill Trust as Time-Bounded, Not Perpetual

The fundamental shift is treating skill approval as a time-bounded assessment, not a permanent grant. Registry trust badges are initial evaluations, issued against a point-in-time state of a dynamic artifact. They should be treated as inputs to an ongoing evaluation process, not as conclusive determinations.

In practice, this means maintaining a living skill inventory that tracks not just what skills are installed but what external resources those skills reference, when those resources were last verified, and what changes have occurred in the content served at those resources. Skills should have defined review periods, analogous to access certification cycles for service account permissions, after which their trust status must be affirmatively renewed based on current behavior, not just initial scan results.

This is the same conceptual shift that moved enterprise vulnerability management from annual assessments to continuous posture monitoring. The threat environment changes continuously. A point-in-time snapshot is a baseline, not a conclusion.

2. Monitor External References for Flip Indicators

The specific mechanism of TOCTOU-based skill attacks, DNS changes, URL redirects, and content modifications, produces observable indicators that can be monitored with existing tooling. For all external URLs referenced by installed skills, implement monitoring for the following:

DNS record changes, including changes to A records, CNAME targets, and TTL values. A DNS change on a domain referenced by an installed skill should trigger immediate re-evaluation of that skill's content and behavior.

HTTP redirect changes, including changes to redirect chains, redirect targets, and intermediate behavior. Worth monitoring, but note that this is not what brand-landingpage did: there the URL never moved and the content behind it was rewritten in place. Redirects are one route to a flip; a stable URL serving new bytes is another, and it is the quieter of the two.

Content hash changes. The content served at a skill's referenced URLs can be hashed at initial evaluation and periodically re-fetched and compared. A content hash change on a URL that feeds into an agent context window is a high-fidelity security signal.

Certificate changes. Certificate transparency logs provide near-real-time records of new certificates issued for any domain. A new certificate issued to a different organization than the original is a strong indicator of domain transfer or takeover.

Most of this monitoring can be automated using existing threat intelligence and domain monitoring services. The monitoring surface is bounded: an organization typically runs a manageable inventory of distinct AI skills.

3. Implement Runtime Behavioral Monitoring for AI Agents

Static scanning at install time must be supplemented with runtime behavioral monitoring. This is the endpoint detection and response equivalent for AI agents: instrumentation capturing what agents actually do at runtime and comparing it against a baseline of expected behavior.

Minimum viable runtime monitoring should capture: all external network calls made during agent execution, including URLs, response sizes, and response content hashes; all tools and function calls invoked during execution; all content passed into the agent's context window from external sources; and all outputs or data transmitted to external endpoints. Deviations from baseline in any of these dimensions should generate alerts for human review.

AI agent framework vendors are beginning to offer observability tooling that captures some of this data. The key is treating this instrumentation as a security requirement, not an optional observability feature, before agents are granted access to sensitive data or high-value systems.

4. Apply Least Privilege Rigorously to AI Agents

AI agents are software principals. They require the same least-privilege discipline as service accounts, API credentials, and human users. In practice, many organizations grant agents whatever permissions are needed to test their full intended functionality at initial deployment. Those permissions are rarely revisited before production.

A rigorous agent permission review should define, for each deployment: the specific external URLs and domains the agent is permitted to call; the specific internal resources the agent is permitted to read; the specific actions the agent is permitted to take; and the specific data classifications the agent is permitted to process. These permissions should be technically enforced at the network and application layer, not just documented in a policy.

For skills specifically, the external URL list defined at deployment should be pinned and monitored. Calls to URLs outside the approved list should be blocked and alerted. Redirect-following, a default behavior for most HTTP clients, should be disabled or strictly controlled for AI agent network clients.

Pinning and redirect control are necessary but not sufficient, and it is worth being precise about why. Neither would have stopped brand-landingpage. That skill called one URL, on one domain, for its entire life; the domain was on any allow-list derived from the approved manifest, and no redirect was ever followed. What changed was the bytes returned. An allow-list answers where may this agent go. Only content integrity monitoring answers is what it found there still what we approved. Deploy both, and do not let the first create confidence that belongs to the second.

5. Establish an AI Agent Supply Chain Vetting Process

AI skills are supply chain components and should be treated as such. A vetting process should include: an initial technical review of the skill's manifest and all referenced external resources; periodic re-review at defined intervals, particularly for skills that fetch external content at runtime; monitoring of referenced domains for flip indicators as described above; and a documented process for rapid revocation and isolation when a skill fails re-review.

This vetting process does not need to be manual. The monitoring surface is small enough that automated re-evaluation at meaningful frequency is practical.

Organizations preparing for SOC 2 trust service criteria assessments or HITRUST certification should note that AI agent supply chain management is increasingly appearing in auditor inquiries. Implementing a documented vetting process now provides both security value and audit evidence. Jacobian Engineering has been incorporating AI agent supply chain controls into client SOC 2 and HITRUST programs since 2025, and the control design is well established even where specific tooling continues to evolve.

6. Design Authorization Policies Around Runtime Behavior

Most enterprise AI governance policies today ask three deployment-time questions: Is the skill from an approved registry? Is the agent on approved infrastructure? Has the deployment been reviewed? These are necessary but not sufficient.

Runtime authorization policies ask different questions: What is this agent doing right now? Is this behavior consistent with its approved function? Is data moving to destinations that were contemplated at deployment time?

Approvals should define behavioral guardrails, not just deployment parameters. An agent approved to process customer support tickets should have its approval conditioned on specific behavioral constraints: it does not access the financial database, it does not transmit to external endpoints outside an approved list, it does not execute function calls outside a defined set. These conditions should be technically enforced, not just documented in policy.

The behavioral guardrail model resembles how financial institutions have long operated controls around high-value transactions: not just approving a transaction type, but monitoring individual transactions against behavioral baselines and flagging anomalies. The principle is directly applicable to AI agents.

7. Maintain an AI Agent Incident Response Plan

When a compromised AI agent skill is identified, the response differs materially from a conventional endpoint compromise. The compromised skill may have operated adversarially for an extended period before detection. The agent's context window during that period may have contained sensitive data from legitimate operations. The agent may have transmitted data to attacker-controlled endpoints. The scope of data exposure is difficult to bound without comprehensive execution logs.

An AI agent incident response plan should address: isolating affected agents without disrupting dependent business processes; forensic review of agent execution logs for the compromise window; identifying all data that transited the agent's context window during that period; assessing whether any agent actions require review or reversal; and evaluating notification obligations under applicable privacy frameworks if the agent processed personal data.

Most existing incident response plans do not specifically address AI agent compromise. Adding a dedicated annex requires accounting for the specific forensic and notification considerations that AI agent compromise introduces.

Conclusion

The browser extension supply chain attacks of 2017 through 2019 demonstrated that install-time trust, applied to dynamic software components with network dependencies, is structurally insufficient. The browser ecosystem eventually responded: enhanced update review processes, tighter developer account security requirements, granular permission model changes. The response took years and required documented, large-scale exploitation to drive adoption.

The AI agent skill ecosystem is at approximately the same inflection point. The brand-landingpage experiment demonstrated the flip mechanism at production scale, with documented evidence. The exploit is not theoretical. The 26,000 install count was real. The redirected endpoint was real. The security stacks saw nothing because they were not looking at the right layer.

The Trusted Skills problem does not require a novel threat actor. It requires any party who can modify a DNS record, update hosted content, or alter a redirect rule for any domain referenced by an installed AI agent skill. That is not a high bar. The attack surface exists in every enterprise AI deployment that uses externally referencing skills, which is nearly all of them.

The organizations that will navigate this with the lowest exposure are the ones that treat AI agent security as a distinct discipline requiring time-bounded trust, runtime visibility, and supply chain rigor, not as an extension of endpoint or static software security models. The core disciplines exist. What is required is their deliberate application before AI agent deployments scale to the point where the attack surface cannot be systematically addressed.

The brand-landingpage experiment closed in responsible disclosure. The browser extension attacks from 2017 did not close that cleanly. The AI agent ecosystem is choosing which pattern it follows.

TrustEdge is the security research and advisory practice of Jacobian Engineering, which provides cybersecurity managed services, compliance assessments, and AI governance consulting for SMBs and healthcare organizations. For AI agent security assessments or Authorization Blindspot risk evaluations, talk to us.