GET-Action Security Boundaries

GET-Action security starts from the assumption that URLs leak. Query strings can enter browser history, server logs, analytics, referrers, caches, screenshots, bookmarks, chat transcripts, and support tickets.

Required controls#

1. Require idempotency_key or nonce for every write-capable GET-Action example.
2. Reject secrets, tokens, passwords, API keys, bearer values, account identifiers, medical identifiers, payment data, private messages, and regulated identifiers in query strings.
3. Require explicit consent for publishing, account changes, repository writes, durable memory writes, destructive actions, payments, private data, or regulated contexts.
4. Apply rate limits, replay handling, crawler protection, and audit logging before action handling.
5. Keep action URLs out of sitemap promotion and public crawler invitations.
6. Return human_review_required or rejected instead of executing ambiguous requests.

Ordering rule#

Security and consent boundaries must appear before examples that could be copied into production. Examples without nearby boundaries are warnings even when the example URL itself is public-safe.

Safe response examples#

{ "code": "human_review_required", "url": "https://example.org/review/agent_req_002" }
{ "code": "rejected", "url": "https://example.org/docs/get-action-security" }