Capability security for lists and agents

Accountless is not authorization-free

Yapture can create a list before a user creates an account. The API returns a list reference and an owner capability. Possession of that capability grants authority.

Treat it like a secret API token:

• Use TLS.
• Keep it out of source control.
• Redact authorization headers and capability URLs.
• Never send it to analytics.
• Store it only for as long as the workflow needs it.
• Rotate or revoke it when the deployed API supports those operations.

References and capabilities

The list ref identifies the object. It should not be treated as proof of authority. The capability establishes the role allowed by the API.

Prefer narrower editor or append-only credentials over owner capability whenever the public contract provides them.

Browser presentation

• Mask capability URLs by default.
• Require explicit reveal or copy.
• Use Referrer-Policy: no-referrer and rel="noreferrer" for permissioned links.
• Do not render secrets into build-time HTML or data-* attributes.
• Use session-only storage by default.
• Distinguish Forget on this device from server-side revocation.

Agent policy

An agent action must satisfy both authorization and user policy. A ranking score or AI recommendation cannot broaden capability scope.

For destructive, external, or high-impact operations, require confirmation and retain visible provenance.

Incident response

If a capability may have leaked:

1. Stop the agent or client using it.
2. Revoke or rotate the capability if supported.
3. Inspect list audit history without copying secrets into the incident record.
4. Reissue only the smallest required access.
5. Document how the secret entered logs, prompts, source, or analytics and close that path.