Security

Security

Fidacy sits on the money path, so its security model is conservative by construction. The guiding rule: the system fails safe, proves everything, and isolates every tenant, at the database, not just the app.

Threat model, OWASP Agentic Top 10

Fidacy exists because agents can be manipulated. We model threats against the OWASP Agentic Top 10, the external-control threat model for autonomous agents. Two are central:

• ·ASI01, Agent Goal Hijack.A prompt-injected or compromised agent tries to act outside the user's intent. Fidacy is an externalcontrol: it checks the mandate against the user's signed intent and the active policy, deterministically. You cannot talk a deterministic check out of denying a hard violation.
• ·ASI04, Supply Chain.An agent's identity or key provenance can't be trusted blindly. Fidacy resolves identity by the RFC 7638 thumbprint of a verified key; an embedded, unverified key is self-asserted and earns no trust, closing the key-confusion and forged-credential path.

Fail-safe by construction

The central invariant runs through the entire codebase: a fault, timeout, or unexpected error degrades to review and is persisted and audited, it never silently approves. Anonymous or hard-violating traffic can never be approved, even by the optional reasoning layer, even under concurrency or partial failure.

Cryptography, JWS / JWKS signing

• ·Risk Payloads are signed with EdDSA (Ed25519) and published as compact JWS. Anyone verifies them against the public JWKS at /.well-known/jwks.json by kid, no Fidacy round-trip needed.
• ·The private signing key is held only in the runtime secret store and never touches the database.
• ·API keys are stored only as SHA-256 hashes; the raw value is shown once. Revocation is instant and takes effect on the next request.

Non-repudiable audit, hash-chain anchored to Bitcoin

Decisions are hash-chained per organization and sealed with Merkle anchors (RFC 6962); UPDATE and DELETE are blocked at the database. The head of the chain is committed to Bitcoin via OpenTimestamps, so the record is tamper-evident and re-verifies offline against the blockchain with a standalone verifier, no party, including Fidacy, can rewrite it after the fact. You can prove to an auditor or counterparty exactly what was decided, when, and on what evidence, the EU AI Act evidence standard.

Enforceable decisions, the payment firewall

For agent-initiated payments the signed verdict is not only advisory. The Payment Firewall is a hard control: the agent calls request_payment, an approve mints a short-lived Ed25519 grant bound to that exact payment, and the executor refuses to move money without it. A denyissues no grant, so a duplicate invoice or a redirected wire (BEC) is stopped by Fidacy, not left to the payment processor or to the integrator's idempotency-key discipline. It is non-custodial: Fidacy authorizes, it never holds funds.

Tenant isolation, FORCE row-level security

• ·Every row is org-tagged and protected by row-level security in FORCE mode, so cross-tenant reads and writes are impossible even under an application bug, the isolation is enforced by the database, not trusted to the app.
• ·The runtime connects as a least-privilege role, not the database owner, so it cannot bypass RLS.
• ·The narrow exception, cross-org discovery for background workers, is gated by a platform-admin SET-scoped GUC predicate inside the RLS policy: it is granted only to the platform-admin context, exposes ids only (never tenant data), and is unavailable to ordinary tenant connections.

Encryption & key rotation

• ·Data is encrypted in transit (TLS) and at rest across the managed database and edge platform.
• ·Signing keys are rotated; the kid in each payload pins it to the key that signed it, so rotation never breaks historical verification.
• ·Use least-privilege API-key scopes per workload, rotate on a schedule, and rotate immediately on any suspected exposure. Secrets live only in your secret manager, never in source control, logs, or screenshots.

Data handling on the decision path

• ·The optional reasoning layer receives only non-sensitive signals (scores, flags, codes), never raw PII or payment credentials.
• ·Assessments store the structured signals needed to reproduce the verdict, not the user's payment-instrument secrets.