Security, authority, and scope
DeAlgo is a control layer for agent financial requests. Its protection depends on routing the relevant actions through the governed path and keeping direct provider credentials away from agents.
Identity and access
Agent connections are restricted to policy requests, proposals, scoped reads, and explicitly authorized evidence reporting for their assigned agent. Administrator sessions are required for mandates, approvals, billing, and merchant connections. Workspace boundaries are enforced on server queries. Session mutations require same-origin JSON.
Approval security
Workspace owners can enable passkey confirmation for policy creation and activation, financial-request approvals, and test-refund submission. Confirmations bind exact terms, expire, and require PIN or biometric verification. Initial setup uses a current DeAlgo password or, for linked-provider accounts when security email is configured, a single-use email code followed by device registration. An enrolled key cannot be replaced through a signed-in session alone. Login 2FA is separate and is not enforced by DeAlgo. Keep the approval device outside agent control; this feature does not certify device independence.
Backup access and recovery
One enrolled key protects approvals; a backup is a spare, not a second key needed for every approval. Owners can register up to five keys, with an existing key confirming each addition. Backup setup can be postponed during testing; arrange separate backup access before relying on this workspace. Revoking a lost key requires a different registered key and signs out account sessions. The last key cannot be revoked. If all keys are lost, self-service approval recovery is unavailable. Email and password recovery cannot remove approval protection.
Money controls
Allowances specify action types, currency, counterparties, maximum transaction size, total budget, and expiration. Proposal reservations, pause, revocation, and approval share a database lock. Exact proposal terms cannot be edited. An approval is permission, not a payment receipt.
Provider credentials
Agent connections do not expose Stripe credentials. Merchant OAuth state is short-lived, single-use, and bound to the administrator and workspace. Subscription webhooks require Stripe signatures and deduplicate events. Sandbox subscriptions do not grant live paid entitlements.
Evidence and uncertainty
Commerce activity is append-only in the application database. This is not independently signed or externally anchored evidence. Backups, database administrator access, recovery drills, and independent security review remain deployment responsibilities.
Current limits
General financial execution is disabled. The refund pilot executes only in Stripe test mode. Controls do not stop agent tools that bypass DeAlgo or reverse payments already submitted. Live merchant activation, authenticated production validation, incident response ownership, legal terms, and regulatory review must be completed before a live-money launch.
No certification claims
This release does not claim SOC 2 certification, PCI assessment, insurance, a guaranteed SLA, AP2/A2A certification, or protection against every attack. Card entry and business verification should stay in Stripe-hosted flows. Do not put card data, banking credentials, tax IDs, or identity documents in proposals.