Skip to content

Security / fail closed

Deny what the system cannot prove.

CAPYN is designed for actions with consequences. Authority must be explicit, current, request-specific and explainable—or execution stops.

Default authorization posture
01Identity established
02Active mandate found
03Every hard rule passes
04Approval valid for this request
05Execution not previously claimed

IF UNKNOWN → DENY

Implemented in v0.1

Security boundaries exist in the server and repository—not in the interface.

The dashboard communicates policy. It does not enforce it. These controls sit in authentication, domain services, transactions and the database model.

Server-resolved identity

The bearer key resolves to one agent and organisation. Strict request schemas reject client-supplied agent identity.

Hashed, revocable agent keys

Generated keys carry high entropy. CAPYN stores an HMAC-SHA-256 hash and short prefix, never the plaintext credential.

Organisation isolation

Every resource read and mutation is scoped with the authenticated organisation; cross-tenant lookups return not found.

Strict input contracts

Zod schemas reject unknown fields, bound metadata size and accept money only as decimal strings converted to integer minor units.

Request-bound approval

An approval applies once to one authorization. Hard policy is re-evaluated under lock at approval time.

Idempotency and replay defense

Agent and idempotency key are unique. Conflicting payloads fail, and completed execution cannot call the provider twice.

Append-oriented audit

Repository interfaces expose append only. A PostgreSQL trigger rejects ordinary update and delete operations on historical events.

Safe operational defaults

Structured logs redact credentials, bodies are capped, errors omit internal details and process-level rate limiting is enabled.

Concurrency / spend reservations

Four simultaneous requests cannot all spend the same remaining budget.

CAPYN serializes authorization and approval accounting per agent, then evaluates projected spend against live reservations inside the same transaction.

Daily limit / $100
REQ 1

$30.00

projected / $30.00

ALLOW
REQ 2

$30.00

projected / $60.00

ALLOW
REQ 3

$30.00

projected / $90.00

ALLOW
REQ 4

$30.00

projected / $120.00

DENY
RESERVED TOTAL / $90.00 · HARD LIMIT PRESERVED

Transparent scope

A developer MVP, not a claim of production certification.

CAPYN v0.1 establishes the architecture and demonstrates its critical controls. It intentionally does not custody or move real funds.

Known v0.1 limitations
Human authentication is a local demo adapter, not production SSO or MFA.
MockPaymentExecutor moves no real funds and does not prove provider reconciliation.
Shared treasury limits across multiple agents require a treasury-level reservation lock.
Rate limiting is process-local rather than backed by a distributed store.
Refunds, reversals, partial capture and currency conversion are not implemented.
Database administrators remain capable of changing data outside application controls.

Production gate

Before any real money moves.

Independent threat model and review
Real human SSO, MFA and sessions
Treasury-level reservations
Distributed abuse controls
Executor reconciliation and outbox
External audit export and retention
Secrets, backups and disaster recovery
Legal and compliance review

Security questions are product questions.

Every limit, approval and audit decision is part of the public product contract—not an implementation footnote.

Start with the decision point

Give the agent a mandate, not the treasury keys.

Run the four-scenario demo locally or inspect the working control plane in the browser.