Most Agent integrations explain what an AI is allowed to do.
They publish a tool list, an OpenAPI document, or an MCP schema. The Agent sees actions such as search, create_order, send_message, or refund and plans from there.
That is only half of the contract.
A production Agent also needs to know what it cannot do, what it must not do, which limits apply, and which actions remain human-gated even when the Agent has broad credentials.
In other words, an Agent interface needs a machine-readable negative space.
Missing tools are not a complete boundary
Suppose an anonymous shopping MCP exposes only one tool: product search.
A careful client may infer that it cannot place an order. But several questions remain:
- Is ordering unavailable on this surface, or merely undocumented?
- Can the Agent obtain a broader tool set after authentication?
- Which write scopes would be required?
- Is a proposed order reversible preparation or a real obligation?
- Does a human still have to approve the final action?
- What happens if the Agent exceeds a rate or cross-user access limit?
The absence of a tool answers none of these explicitly.
Prompt instructions are not enough either. A sentence such as “do not buy without permission” depends on model behavior. A server-enforced capability boundary can return a deterministic denial. A machine-readable boundary lets the client understand that denial before it improvises a recovery path.
Five kinds of "no"
A useful negative-space document should distinguish at least five categories.
1. Unavailable
The capability does not exist on this interface.
Example: an anonymous discovery endpoint can search but cannot create an order or move funds.
2. Scope-gated
The capability exists, but the current identity has not declared or received the required scope.
The server should default to deny rather than treat an unknown Agent as broadly trusted.
3. Rate-limited
The action is permitted within an explicit budget. The limit, unit, and failure response should be predictable enough for a client to stop rather than retry aggressively.
4. Forbidden
Some behavior should remain disallowed regardless of convenience: impersonation, exceeding declared scope, reselling user data, or rebuilding a cross-user profile graph from protocol reads.
5. Human-gated
Some actions remain too consequential for a delegated scope to override. Arbitration, key revocation, account deletion, or large withdrawals may require a fresh human ceremony even when the Agent is otherwise authenticated.
These categories produce different recovery behavior. “Unavailable” may send the user to another interface. “Scope-gated” may request authorization. “Rate-limited” should wait. “Forbidden” should stop. “Human-gated” should hand off a precise action for confirmation.
Documentation is not enforcement
A negative-space file is useful only when it matches runtime behavior.
The strongest version connects each declared boundary to an enforcement mechanism:
- named write scopes map to actual routes or tool actions;
- undeclared writes fail closed;
- rate caps produce stable error codes;
- repeated abuse changes an accountability state;
- sensitive transitions require a live human ceremony;
- limits are versioned with the same contract the Agent reads.
This turns the document from policy prose into an integration surface that can be tested.
A live example
WebAZ publishes both sides of its Agent contract.
As checked on September 2, 2026, its public protocol reported version 0.1.37 and schema 49.
The positive capability map is available at:
https://webaz.xyz/.well-known/webaz-capabilities.json
It describes named write actions, read scopes, safe unscoped operations, and default-deny behavior for undeclared Agent writes.
The negative space is available at:
https://webaz.xyz/.well-known/webaz-negative-space.json
It lists forbidden behavior, cross-user and mass-action limits, consequences for repeated abuse, and an iron rule: certain sensitive actions require live WebAuthn regardless of declared scope.
The public shopping surface demonstrates the smallest version of the idea. Its anonymous tool list exposes only webaz_search. Account, order, reservation, and settlement actions are not present on that surface.
This is an implementation example, not a claim that the design is complete or universally secure. A published boundary still needs adversarial tests, monitoring, and review. The useful property is that a client can inspect the intended boundary and compare it with observed behavior.
A practical test for Agent builders
For one MCP server or Agent API, ask:
- Can the client enumerate what this identity may do?
- Can it distinguish unavailable, scope-gated, rate-limited, forbidden, and human-gated actions?
- Does every consequential write have a named authorization boundary?
- Are denial and retry states deterministic?
- Can the client learn which actions must stop instead of escalating automatically?
- Is the boundary versioned and testable against the live service?
Agents become more useful when they can act. They become more trustworthy when they can explain why they stopped.
Publishing a machine-readable yes is the start of an integration. Publishing an enforceable, machine-readable no is what gives that integration a boundary.
WebAZ integration contract: https://webaz.xyz/.well-known/webaz-integration.json
Capability map: https://webaz.xyz/.well-known/webaz-capabilities.json
Negative space: https://webaz.xyz/.well-known/webaz-negative-space.json
Top comments (0)