Relay configuration and status freshness

Wake-up relay (webhooks)

An agent that cannot wait in-session learns that its action changed through a wake event delivered to a webhook it (or its runtime) operates. The event is a hint to read status. It carries no state the agent may act on, cannot grant authority and cannot execute anything.

Console: Webhooks at /app/projects/:pid/webhooks. You need project.write.

POST /v1/projects/{project_id}/webhooks
content-type: application/json

{
  "url": "https://agent-runtime.acme.example/axiom/wake",
  "events": ["action.changed"],
  "agent_id": "agt_…",
  "tenant_id": "ten_…"
}

• url must be HTTPS (plain HTTP is accepted only in development).
• events defaults to ["action.changed"]; "*" also matches.
• agent_id and tenant_id narrow delivery to one agent's or one tenant's actions. Set them on a shared project so one customer's runtime never receives another customer's events.
• The response includes verification_keys, the JWKS URL to verify events with (key role event).

What is delivered

Every state change of a matching action produces one delivery:

POST /axiom/wake
content-type: application/jose
axiom-event-id: evt_…:act_…:7

eyJ0eXAiOiJheGlvbS1ldmVudCtqd3MiLC…

The body is a compact JWS (typ: axiom-event+jws) whose payload is only:

{
  "v": "axiom.event.v1",
  "event_id": "evt_…:act_…:7",
  "type": "action.changed",
  "action_id": "act_…",
  "tenant": "ten_…",
  "occurred_at": "2026-11-14T18:10:00.000Z",
  "seq": 7
}

No amounts, beneficiaries, names or summaries leave Axiom in a wake event, so a relay in between learns nothing about the transaction. seq is the action's sequence number at the time of the change, so a delayed delivery is recognisably older than a later one.

Delivery behaviour

• At least once. A non-2xx answer or a timeout (10 s) is retried with backoff (5 s doubling, at most 1 hour apart), up to 10 attempts; then the delivery is marked dead.
• Receivers must deduplicate by (action_id, seq) and drop lower sequence numbers. The SDK's WakeEventReceiver does this (see Webhooks and relay).
• seq and occurred_at are stamped when the change happens, not when a retry is sent, so a retry of an old event is recognisably older than a later event.
• The SDK accepts events up to 24 hours old by default (maxAgeSeconds 86,400, which covers the whole retry schedule) and reads authoritative status for every verified delivery, fresh, duplicate or stale alike. Deduplication by (action_id, seq), not the age limit, is the replay defence. Agents should still poll on their own schedule rather than rely on a single delivery.

Relays you operate

If the agent's runtime cannot accept inbound HTTPS, put a relay in front of it: the relay forwards the JWS untouched, and the agent verifies the signature itself. A relay that alters an event breaks the signature; one that drops events only delays the agent until its next poll. Neither can make anything execute.

Status freshness

Gateways

Customer-hosted gateways and adapters fetch a policy and trust bundle, signed by Axiom's policy key, on every heartbeat. The bundle carries the active policies, trust data (issuer keys, tenant trust profiles, suspended agents, revoked credentials and grants) and every emergency deny that can affect the project.

Freshness	Rule	What it means
fresh	The last bundle is less than 300 seconds old (fresh_until).	The gateway is enforcing current policy.
stale	No valid bundle, but contact within the last 15 minutes.	The gateway must keep sensitive writes blocked or pending.
offline	No contact for more than 15 minutes (or never).	Treat its enforcement as unknown; its cached bundle shows cached_bundle_valid_until.

Fleet and gateway screens show each gateway's freshness, last contact, policy_version_acked and fresh_until. See Fleet, gateways and cutover.

The 300-second window is a single fixed value in this release. Class-specific freshness windows (for example shorter for sensitive writes) are a pilot decision.

Tenant trust profile

The Trust profile screen (/app/tenants/:tid/trust) also accepts accepted_issuers and status_freshness_seconds (30 to 86,400, default 300).

Stored, not yet enforced

status_freshness_seconds and accepted_issuers are saved with the trust profile but are not used by any decision in this release. Only workload_issuers changes behaviour. Do not rely on the freshness value to bound revocation propagation; the effective bound is the 300-second bundle window above (and immediate effect on the hosted gateway).

Hosted gateway

The Sectigo-hosted gateway, the REST API and the MCP endpoints read policy, grants, suspensions and emergency denies from the database on every decision, so a change applies to the next request with no propagation delay.