Expose business APIs as agent tools

A Tool Provider does not hand an entire OpenAPI surface to a model. It compiles explicitly enabled business actions into governed tools.

Minimal OpenAPI + ACC declaration

{
  "openapi": "3.1.0",
  "info": { "title": "Order tools", "version": "1.0.0" },
  "paths": {
    "/orders/{id}": {
      "get": {
        "operationId": "order.get",
        "summary": "Read an order",
        "x-agent-capability": {
          "version": 1,
          "enabled": true,
          "scope": "order.read",
          "risk": { "level": "low" },
          "subject": { "required": true }
        }
      }
    }
  }
}

Operations without enabled: true stay hidden. The route applies a second, precise scope/operation allowlist.

Catalog access policy

Policy	Use it when
signed_required	Default. The hub signs catalog reads and performs unsigned/bad-signature negative probes
public_allowed	An administrator explicitly accepts public disclosure of paths, parameters, and governance metadata

A public catalog never makes real tool calls public. Protected catalog responses should use Cache-Control: private, no-store, and neither policy follows redirects.

Two gates

1. The hub governs reach: route allowlists, risk, approval, rate limits, idempotency, signing, and audit.
2. The business system owns authority: after signature verification, evaluate X-Bailing-On-Behalf-Of, tenant, resource ownership, and current state.

Signature verification proves origin, not permission.

Design business actions, not raw CRUD

Shape	Example	Guidance
Query	order.get	Read-only, low risk
Preview	refund.preview	Return impact without side effects
Request/draft	refund.request.create	Continue in the business workflow
Execute	refund.execute	High risk or parameter-based approval
Batch	price.batch.update	Precise operation allowlist and stricter approval

Do not hide authorization or risk rules in prompts. See ACC and the fixed v0.9.0 tool guide.