AuthorityRailExecution Authority Infrastructure
Developers

Authority for every autonomous action your code takes

The AXAP SDK is the TypeScript client for the AuthorityRail Authority Gateway. Drop it in at every point where an agent, an LLM-backed application, an MCP tool, an RPA workflow, a voice command, or an edge inference path would otherwise execute a real-world action. Every decision returns a Certified Action Record before impact — and the SDK verifies that record client-side against your federation manifest.

Honest framing: AXAP is GA at v3.9.0. Cryptographic primitive review pending per ARES-v1.1 §16. Authority Gateway public publication pending. Mapped, not yet third-party audited.

Tell us what you’re building

Five fields. We reply within two business days, by name, from a person. Indie devs, platform engineers, and founding engineers all welcome — the SDK is the same shape regardless of company size.

We use this only to reply. Your data follows our Privacy Policy and our Security posture. No marketing automation, no list resale, no tracking pixels. Developer signups are tagged ar_audience: developer in HubSpot to keep them out of the enterprise procurement queue.

Getting started

While we're typing back, here's the integration shape so you can start playing locally. The SDK is on npm; you don't need to wait for us.

Install

npm install @authorityrail/axap@3.9.0

Authorize an action

import { createClient } from '@authorityrail/axap';

const ar = createClient({
  gateUrl: 'https://gate.authorityrail.com',
  agentId: 'urn:ar:agent:my-service',
  orgId:   'org_replace_me',
  apiKey:  process.env.AR_API_KEY,
});

const result = await ar.authorize({
  action: 'transfer_funds',
  risk_score: 0.8,
  payload: { amount_usd: 12500, dest_account: 'ACME-Corp-Ops' },
});

// result.decision is 'ALLOW' | 'DENY' | 'ESCALATE' | 'BLOCK'
// result.car_id is the verifiable Certified Action Record id

Full SDK README on GitHub — full integration patterns including Authority Constraints API, Provenance Tagging middleware, Ghost Call Detection, and ARES-v1.2 verification.

Companion documents: /security · /trust · /security/disclosure · /contact (enterprise procurement)

request limits

Request body size limit

The gate caps every /v1/execute request at 256 KiB. Bodies above that limit are rejected at ingress with HTTP 413 Payload Too Largebefore the request reaches the auth gate, scope check, or decision pipeline.

Why this exists

CARs are small by design. The 99th-percentile observed payload is well under 50 KiB. A 256 KiB cap leaves headroom for unusual structured-evidence payloads while protecting the gate from accidental or hostile oversized bodies. The cap is configurable per deployment via the AR_BODY_LIMIT environment variable.

Error envelope on rejection

HTTP/1.1 413 Payload Too Large
Content-Type: application/json

{
  "success": false,
  "data": null,
  "error": {
    "code": "REQUEST_BODY_TOO_LARGE",
    "message": "Request body exceeded the configured limit (256kb). See https://authorityrail.com/developers#size-limits."
  }
}

If you legitimately need a larger body

Most callers do not. Patterns to consider before requesting a larger cap:

  • Move large evidence blobs out-of-band (S3 / R2 URL) and reference the URL by hash.
  • Split a long execution sequence into multiple CARs linked via the CAR Chain.
  • For Voice Governance: use the streaming voice-gate surface, not the JSON body.

If after those, you still need a larger limit on a private deployment, contact enterprise procurement.

Observability

Every 413 increments the ar_request_too_large_total Prometheus counter (labelled by route). Operators can wire alerts on this counter to spot upstream agents that have drifted into oversized payloads.