Reference

The policy file

A policy is a short YAML file that states what an agent may call, what it may see and what needs a person to authorize. Absorb compiles it with your OpenAPI specification into the exact tool surface agents receive, and the same inputs always produce the same output.

Book a demo See it working

A complete policy

The policy from the walkthrough, compiled against a ticketing API with 15 operations. Three become tools, and the other twelve are withheld with a reason.

agent.yamlreviewed like IAM

allow beats nothing, deny beats allow, writes must be named
allow:
  - GET /tickets
  - GET /tickets/{id}
  - POST /tickets/{id}/comment

deny:
  - DELETE
  - /admin/**
  - /internal/**

fields:
  Ticket:
    include: [id, status, priority, summary, blocker_flag, assignee.name]
    exclude: [customer_email, ssn, raw_description]

params:
  deny: [include_deleted, internal]

limits:
  response_bytes: 8000
  max_tools: 12

tools:
  POST /tickets/{id}/comment:
    name: add_comment
    approve: true
    conditions:
      - arg: id
        from_claim: ticket_scope

absorb diff15 to 3 tools

$ absorb diff --spec tickets.yaml --policy agent.yaml

  15 operations to 3 tools, 12 withheld
  contract 7.1 KB to 1.1 KB  (-83.8%)

Exposed (3)
  + search_tickets  GET    /tickets
  + get_ticket      GET    /tickets/{id}
  + add_comment     POST   /tickets/{id}/comment

Withheld (12)
  - DELETE  /tickets/{id}      denied by DELETE
  - GET     /admin/audit       denied by /admin/**
  ... 10 more

Precedence

Nothing is exposed unless an allow rule names it.
A deny rule beats any allow rule.
Write operations must be named explicitly. A write matched only by a wildcard is withheld.
The same specification and policy always compile to the same tools.

Keys

Key	Effect
`allow`	Operations the agent may call, written as `METHOD /path`. An operation no allow rule names is withheld as not allowlisted.
`deny`	Methods such as `DELETE` or path patterns such as `/admin/**` that are never emitted, whatever the allow rules say.
`fields`	Per response schema, the fields to `include` and to `exclude`. Nested fields use dotted paths such as `assignee.name`. Undocumented fields are removed by default.
`params.deny`	Parameters removed from every tool's arguments. An operation that requires a denied parameter is withheld.
`limits.response_bytes`	Size cap applied to each response before it reaches the agent.
`limits.max_tools`	The largest number of tools the compiled surface may contain.
`tools`	Overrides per operation, keyed by `METHOD /path`: `name` renames the tool, `description` replaces the specification's text, `approve: true` holds every call for a human decision, and `conditions` restrict arguments.

Conditions on arguments

Rules under a tool restrict what an agent may pass, before anything reaches the API. They live in the policy file, so they are reviewed and versioned with everything else.

tools:
  POST /orders:
    name: create_order
    conditions:
      - arg: tenant_id
        from_claim: tid
      - arg: body.amount
        max: 10000
        approve_above: 1000
      - arg: body.currency
        one_of: [EUR, USD]
      - arg: reference
        pattern: "^INV-[0-9]{4}$"
        max_length: 12
      - arg: reason
        required: true

Rule	Effect
`from_claim`	Sets the argument from the caller's token claim, overwriting whatever the agent sent. The call is refused if the token has no such claim.
`max`, `min`	Numeric bounds.
`equals`, `one_of`, `pattern`, `max_length`	Value restrictions.
`required`	The argument must be present.
`approve_above`	Above this number the call needs human approval, even if the tool is not marked `approve`.

arg takes a dotted path, so body.amount reaches into a JSON request body.
A refused call never reaches the API. It is audited as reject with the reason condition, and the agent receives the list of problems so it can correct itself.
from_claim pins a tenant or customer identifier to the signed-in agent instead of trusting its arguments.

Reading the result

absorb diff lists every exposed tool and every withheld operation with its reason. absorb diff --html report.html writes the same result as the review document, and absorb lint flags tools whose descriptions are too thin for accurate selection.

Withheld reason	Meaning
denied by a rule	A `deny` rule matched the method or path, and the report names the rule.
not allowlisted	No `allow` rule names the operation.
write needs an explicit rule	A write was matched only by a wildcard.
required param is denied	The operation needs a parameter that `params.deny` removes.

Compile your own API and assess the result

Send a specification. We will show the tools it produces, the operations it withholds, and the document your security function would review.

Book a demo See pricing