Allowly

Agent action authorization and signed receipts.

Signed audit receipts for every AI agent action.

Every team shipping AI agents hits the same wall: the agent has broad access to a user's data, there's no runtime check on what it does per action, and nobody can prove after the fact what was authorized and what wasn't.

Allowly is the runtime permission layer for that problem. Your app calls POST /v1/check before every action. Allowly evaluates the request against an active user authorization, returns a decision, and produces a signed, tamper-evident receipt that a third party — your auditor, your customer, a regulator — can verify offline years from now.

How it works

User approves scopes
        │
        ▼
POST /v1/authorizations  ──► authorization_id (store this)
        │
        ▼ (before every agent action)
POST /v1/check
  authorization_id + scopes[] + resource
        │
        ▼
{ decision: "allow" | "deny" | "confirm" | "escalate" }
+ receipt envelope (pending → signed async)
        │
        ▼
GET /v1/receipts/{id}  ──► signed receipt
        │
        ▼
Verify:
  offline with workspace public key
    GET /v1/workspaces/{id}/keys
  online by authorization_id
    GET /v1/receipts?authorization_id=auth_...

The two verification paths serve different jobs. Use GET /v1/receipts?authorization_id=auth_... when support, a customer, or an auditor needs the full trail for one authorization: creation, each scope check, escalation decisions, and revocation. Use the workspace public keys to verify the signature on each signed receipt offline. The online receipt list is for discovery and audit reconstruction; the signature is the proof.

The decisions

Decision	Meaning	What to do
`allow`	Authorization covers this scope, active, not expired	Proceed
`deny`	No matching authorization, revoked, expired, or scope not covered	Block — log the denial
`confirm`	Authorization exists but this scope requires explicit user re-approval	Prompt the user, then call `POST /v1/confirmations/{nonce}`
`escalate`	Authorization exists but this scope requires third-party approval	Route to the configured approver, then call `POST /v1/escalations/{id}/resolve`

The receipt

Every decision produces a signed receipt. The receipt is the artifact that outlives the API call:

Signed with your workspace's Ed25519 signing key, managed by Allowly and never exposed to customers
Structured as canonical JSON, verifiable offline by any third party with your public key
Immutable — once signed, it cannot be modified without invalidating the signature
Chains to an authorization_id so the full audit trail (authorization granted → scope checks → revocation) is reconstructable

Signing happens asynchronously off the decision hot path. The /check response returns a pending receipt envelope immediately, so your app can enforce the decision while the signed receipt is prepared.

What Allowly is not

Not an authorization management platform (banners, cookie flows, GDPR marketing authorization)
Not an authorization engine (RBAC, ABAC, policy DSL)
Not an OAuth server

Allowly sits on top of whatever auth system you already have. It records what your agent was permitted to do, and proves it.