How verification works
A badge answers one question: do we know who published this?
It is a claim about identity, not about behaviour. We have not audited what a skill does, and a verified publisher can still write a bad one. What the badge buys you is someone to hold responsible — which is exactly what is missing when an agent picks up instructions from a stranger.
The tiers
SkylarkWritten and maintained by the Skylark team.
Permission ceiling: Everything, including running JavaScript
Published by an organisation whose identity we confirmed. It does not mean the skill has been audited.
Permission ceiling: …plus tabs and network reads
The publisher proved they control this domain. It does not mean the skill has been audited.
Permission ceiling: …plus tabs and network reads
Submitted by a community member and reviewed by a curator before publishing.
Permission ceiling: Read the page, act on the page, navigate
Earning a verified domain
Two proofs, either sufficient. Both work on the same principle: only whoever controls the domain can arrange them.
Origin proof
Serve the skill from your own site at /.well-known/agent-skills/index.json. We fetch it, match the name and digest, and that is the proof. Nothing to configure.
This one is re-checked every 30 days. A site that stops publishing has stopped making the claim, so the badge lapses rather than outliving its evidence.
DNS proof
Add a TXT record with the token we issue you. Useful when the skill lives somewhere other than the site it drives.
_skylark-skills.acme.example. TXT "skylark-skills-verification=…"Verified organisation
The filled badge means a curator confirmed a real organisation is behind the publisher, out of band. It is granted by a person and does not expire on a timer. We use it sparingly — it is the strongest thing this directory says about anyone.
Why permissions are capped by tier
Publishing a skill to a directory means shipping instructions to every Skylark user who visits that site. That is a distribution channel, so the interesting question is not what a skill asks for but what we let it hold.
A site-published skill is capped at the powers the site already has over its own page: reading it, clicking its own buttons, setting its own URL. Granting those adds nothing the origin could not already do. The powers a site does not have — reading your other tabs, reading raw network bodies where your tokens live, running JavaScript with access to your cookies — are reserved for tiers where a human vouched for the publisher.
| Permission | What it allows |
|---|---|
| page:read | See the content and structure of the page you are on. |
| page:act | Click, type, and interact with controls on the page. |
| navigate | Follow links and move backwards and forwards within the site. |
| tabs | List, open, switch between, and close tabs. |
| network:read | Inspect requests and responses, which can include tokens. |
| js:evaluate | Execute arbitrary code in the page, with access to cookies. |
| network:intercept | Modify or block requests the page makes. |
And regardless of any of this
Permissions decide which tools a skill may drive. They do not decide whether something consequential can happen quietly. A purchase, a deletion, a form carrying your details — those stop and ask you, whatever the skill's instructions say. A skill can click; it cannot buy.