Security
Armalo鈥檚 security posture is centered on trustworthy operations: scoped access, inspectable evidence, and operator control over what agents are allowed to claim and do.
Tenancy And Scope
API keys, org scoping, and policy boundaries keep one team鈥檚 trust and control surfaces isolated from another鈥檚.
Verification And Auditability
Pacts, eval artifacts, attestations, and webhook signatures create evidence that a reviewer can inspect rather than trust by assertion.
Operator Visibility
Runtime governance and review flows make it easier to inspect important actions, route exceptions, and see where trust is weakening.
Security review checklist
- Confirm which API keys, scopes, and org boundaries are required.
- Review how webhook signatures and attestations are validated.
- Map where pacts and evals create evidence for runtime behavior.
- Decide which operator controls or review steps are required before broader rollout.
- Verify how deployment mode changes the trust and control envelope.
Control matrix
Use this matrix to turn a security review into concrete evidence requests. The important question is not whether a feature exists; it is whether the control can be inspected under real tenant, billing, and runtime conditions.
API keys
Control: Hashed storage, scoped permissions, server-side use for mutation, and revocation through dashboard settings.
Reviewer asks: Confirm the exact scopes needed for agents, pacts, evals, trust queries, and webhook administration.
Mutable API routes
Control: Route governance classification, organization ownership checks, explicit auth mode, and audit event emission.
Reviewer asks: Verify that write routes cannot mutate another tenant and that unknown-auth routes are treated as release blockers.
Webhooks
Control: One-time secret return, HMAC-SHA256 signature on the raw body, retry metadata, and event allowlists.
Reviewer asks: Process only verified payloads, store delivery IDs idempotently, and alert on repeated delivery failure.
Runtime governance
Control: Operator approvals, policy checks, runtime receipts, and explicit failure or simulation labels.
Reviewer asks: Require evidence before promoting autonomous actions from simulation or dry-run mode to production mode.
Escrow and payments
Control: Whop billing for subscriptions, x402 or escrow paths for usage/payment flows, and release-truth smoke artifacts.
Reviewer asks: Treat legacy Stripe paths as compatibility only. New billing and checkout work should use Whop.
Failure and incident behavior
- Fail closed when auth, tenancy, webhook signature, payment truth, or runtime evidence is missing.
- Return a request ID or audit reference for supportable failures whenever the caller is authenticated.
- Keep public errors generic, but preserve internal blocker reasons for operators and auditors.
- Separate unavailable evidence from negative evidence. A missing eval result should not be presented as a passed eval.
Ready to map security review into production rollout?