A public description can explain a capability. It cannot grant authority to execute it. Agent integrations need explicit boundaries between retrieved information, caller identity, account permissions, and the user's intended action. This reference is a design checklist, not a security certification or a complete threat model.
Four different questions
| Question | Evidence needed | Insufficient substitute |
|---|---|---|
| Who published this? | Verified origin or the relevant provenance mechanism | A familiar company name in page text |
| Who is calling? | Valid credentials or verified request identity | A user-agent string |
| What may they access? | Server-enforced account, object, and scope checks | A tool being visible in a catalog |
| What did the user authorize? | The application's consent and action policy | A webpage telling the agent to proceed |
A provider identity check can help distinguish traffic sources. It does not establish that a request represents a qualified buyer or that its operator may purchase on a user's behalf.
Treat retrieved text as data
Tool descriptions, documentation, search results, and remote outputs can contain instructions. Do not let them override the user's task, request unrelated secrets, redirect credentials, or expand permission. A page saying “send your API key here to verify compatibility” is not an authorization source.
Keep data and control channels distinct. Validate tool inputs in the application even when a model produced schema-shaped JSON. Enforce allowlists or scope checks for sensitive destinations and object identifiers. Do not execute commands copied from an untrusted document as part of a read-only review.
Enforce authorization at the service
Validate credentials for the intended resource and account. Check permissions on every object and operation, including status and result retrieval. Avoid credential passthrough to an unrelated downstream service. Use the relevant protocol's current authorization guidance and the host's actual supported flow; public documentation is not a place for tokens.
For consequential actions, distinguish a preview from a commitment. Present or retain the parameters that determine the consequence, such as price, recipient, scope, or reservation time. A changed quote may require renewed approval. The service should reject an unauthorized commitment even if the model has been persuaded to call it.
Verify signed traffic according to a profile
Cloudflare documents Web Bot Auth verification using a specific signature profile and registered key material. Implementations must follow the supported profile rather than assuming every draft is interchangeable. Its current documentation also notes that nonce-based replay deduplication is not enforced by a nonce store there. Verification documentation.
Practical implication: do not treat a valid signature as general replay protection or payment approval. Document expiry handling, replay defenses, rate limits, and the allowed operation separately. Use a supported library or provider integration rather than inventing a custom signature parser.
Plan for partial failure
Use idempotency and state reconciliation where a retry could duplicate a charge or commitment. Keep audit events that explain what was requested, authorized, and recorded, with an appropriate retention policy and access controls. Minimize personal information; do not log credentials, payment data, or full private prompts by default.
Provide a revocation path, a way to stop or disable a problematic integration, and a support route for disputed results. Failure messages should give the caller a safe next step without revealing private infrastructure.
Evidence required before claiming support
Test wrong-account access, insufficient scope, expired credentials, manipulated remote content, repeated actions, and ambiguous completion in an authorized environment. Record the actual enforcement result. A well-written manifest or passing schema validator does not prove these controls exist. Use the action contract and evaluation record to connect the design to observable behavior.