Security

How we protect your data and systems

Data Encryption

We employ industry-standard encryption to protect your data:

  • At Rest: All data is encrypted using AES-256
  • In Transit: All communications use TLS 1.3
  • Audit Logs: Cryptographic hash chaining ensures tamper-evidence

Access Control

We implement strict access controls at every level:

  • Role-based access control (RBAC) for user permissions
  • Multi-factor authentication support
  • API key management with scoped permissions
  • Multi-tenant isolation via application-level org scoping on every API query (with CI lint against regressions). Postgres row-level security is enabled on tenant tables as defense-in-depth preparation; it is not yet the load-bearing per-request boundary for the API’s pooled database connection (staged re-architecture in progress).

Infrastructure Security

Our infrastructure is designed with security in mind:

  • Hosted on secure cloud infrastructure with regular security updates
  • Network segmentation and firewall rules
  • Regular security assessments and monitoring
  • Automated threat detection and alerting

SSRF Protection

The HTTP proxy connector includes built-in protection against Server-Side Request Forgery (SSRF) attacks:

  • Blocks access to private IP ranges (10.x, 172.16-31.x, 192.168.x)
  • Blocks access to cloud metadata endpoints
  • Blocks localhost and loopback addresses
  • Configurable allowlist for internal services

Audit Trail

Every action is logged with cryptographic integrity:

  • Immutable audit logs with hash chaining
  • Complete action history with full context
  • Exportable proof packs for compliance-readiness
  • Configurable retention periods

Policy Engine

The OPA-based policy engine provides defense in depth:

  • Declarative policies using Rego language
  • Default-deny security model
  • Real-time policy evaluation
  • Human-in-the-loop for sensitive actions

Availability & Failure Modes

We believe you should know exactly how the firewall behaves when things go wrong, not just when they go right:

  • Policy evaluation is default-deny. When policies are evaluated, actions that do not match an allow rule are denied or routed to human approval.
  • Reachability gate: when the org enforcement mode is unknown or the check times out, the gate fails closed (deny). When mode is confirmed open and only grant lookup fails, it fails open (allow-by-default posture). Mode unknown never silently allows.
  • Policy cascade (OPA → DB rules → heuristics) defaults to fail_open on tier unreachability (fall through). Orgs can opt into fail_closed (deny at the failed tier) via the setup wizard or PUT /v1/orgs/policy-cascade-mode.
  • Performance: the decision pipeline targets low-latency allow/deny on fast path and cache hits; full OPA evaluation is higher. Live latency is exposed on the API /health and /health/metrics endpoints rather than a fixed marketing SLA.

Detailed failure-mode documentation for the reachability layer is available to customers and design partners on request.

Compliance Status

The platform is built to SOC 2 control objectives(security, availability, confidentiality), including tamper-evident audit logging, tenant isolation, encryption at rest and in transit, and access controls. A formal SOC 2 audit is planned; we do not yet hold a SOC 2 report and we won’t claim one until an independent auditor issues it.

Threat Model

We maintain an internal threat model covering the attack surfaces we defend against, with mitigations and abuse-test scenarios for each:

  • Cross-tenant data access: org-scoped queries on every request with JWT-derived org identity (never from untrusted request parameters); application-level org_id filters are the primary tenant boundary for the API path today. Database RLS policies exist on tables but are not the per-request enforcement mechanism for the API’s current connection role until the staged per-request GUC / app-role rollout completes.
  • Policy bypass: server-side policy evaluation, TOCTOU protection via parameter hashing at approval time
  • SSRF: private-range, metadata-endpoint, and loopback blocking in the HTTP proxy
  • Denial of service: per-org rate limits and blast-radius caps
  • Audit trail tampering: append-only, hash-chained events with scheduled chain verification
  • Authentication bypass: SHA-256-hashed API keys, JWT validation, progressive lockout on repeated auth failures
  • Privilege escalation: role-based access control with admin-only routes

The full threat-model document is available to customers and design partners on request via security@agentactionfirewall.com.

Responsible Disclosure

We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly:

Safe Harbor: We will not pursue legal action against security researchers who discover and report vulnerabilities in good faith, following the guidelines above. We consider good-faith security research to be authorized and will work with researchers to understand and resolve issues quickly.

Contact

For security-related questions or to report a vulnerability, please contact us at security@agentactionfirewall.com