A skill is untrusted text a fleet will follow.

Here is how it could be poisoned, what already prevents that, and what we do not claim to have solved.

Why this document exists

A compiled skill is a procedure written from a recording of a person and handed to every agent that hits the same wall. That makes it the most powerful object in the system and the most attractive target: poison one skill and you steer a fleet. Enterprise security reviewers ask about this first. This is the answer, written before they ask.

Who could poison a skill, and how

What is in place

• Skills are scoped to the customer and to the site. Every skill is tagged with its owner and the host it was learned on; retrieval puts both into the query, so a skill can only ever answer its own customer's agents on its own site (T4).
• Typed text is never recorded. The recorder keeps one frame per action and deliberately no keystrokes; secret-looking fields are stripped from element capture; the writer is instructed to never include a credential and to write "enter the account email", not the email (T6).
• The compiler refuses more than it invents. It is told to trust the screenshots over the task text, to answer UNCLEAR when the recording does not show the task succeeding, and a refusal writes nothing. Observed live: a task claiming a terminal over screenshots of a calculator produced a refusal, not a procedure (T3, T5).
• Every skill carries an authority boundary. Logins, one-time codes, CAPTCHAs and consequential approvals are written as "stop and ask for a human", never as steps. The boundary is a structured field the agent receives with the skill (T1, T3).
• Skills are trusted once, then by their record. A fresh skill is offered once; if the agent comes back it gets a human, and a skill that fails three times without ever working retires itself. A customer can retire any of their skills from the portal, and pause it without deleting it (T1, T5).
• Fix links are single-purpose and short-lived. One link per intervention, bound to that intervention, dead on close, rate-limited, and every action taken through it is in the audit trail with the time (T2).
• Public targets only, unless the customer says otherwise. Private, loopback and metadata addresses are refused for hosted fixes; a customer may allowlist hosts for their own runtime, which is on their network, not ours (T3 variants that pivot inward).
• Everything is recorded. Who opened a fix, what happened in it, what compiled, who retired what. The oversight record for any fix is exportable (all).

What is not solved, stated plainly

• A determined fixer with a legitimate link can still teach a bad procedure. The controls make it visible and reversible, not impossible. Restricting who may hold fix links is the customer's roles configuration.
• Prompt injection against the compiler is mitigated, not eliminated. The writer reads screenshots; text on screen is data to it, but a sufficiently crafted page could still influence wording. Review of new skills before first use is available to any customer who wants it, and is the default we recommend for regulated workflows.
• The vision model is a third party. Screenshots of the fix are sent to it for compilation. Data-processing terms are on the security page; a self-hosted model is an enterprise option.

Reporting

Responsible disclosure to security@doubleoh.ai or through the contact page with the topic set to security. We credit reporters.