Trust Center
This page describes how AxonFlow protects customer data, enforces isolation between tenants, manages secrets, and supports compliance workflows. Every claim on this page references shipped capabilities in the current platform release.
AxonFlow is source-available under BSL 1.1. The entire platform codebase is inspectable — security teams can audit the implementation directly rather than relying on marketing claims.
Security architecture
Multi-tenant data isolation
AxonFlow enforces tenant isolation at the database level using PostgreSQL Row-Level Security (RLS).
Every customer-data table has RLS policies that filter rows by org_id. The enforcement mechanism:
- Each inbound request sets
app.current_org_idas a PostgreSQL session variable viaSET LOCAL - RLS policies on every table evaluate
current_setting('app.current_org_id')in theirUSINGclause - Queries return only rows matching the authenticated organization — no application-level filtering required
Two database roles enforce the separation:
| Role | Privileges | Purpose |
|---|---|---|
axonflow_app_role | NOBYPASSRLS | Handles all request-path traffic. Cannot bypass RLS under any circumstance. |
axonflow_platform_admin | BYPASSRLS | Used only for cross-tenant administrative operations (migrations, tenant provisioning, GDPR erasure). Never exposed to request traffic. |
FORCE ROW LEVEL SECURITY is enabled on all customer-data tables, which means RLS policies apply even to the table owner. This prevents a misconfigured connection from accidentally bypassing isolation.
Network security
AxonFlow runs as two services (Agent and Orchestrator) behind a load balancer. The network architecture enforces:
- External traffic: TLS-terminated at the Application Load Balancer. No plaintext HTTP accepted.
- Internal service communication: Agent ↔ Orchestrator traffic stays within the private subnet. Security groups restrict ingress to the load balancer and inter-service ports only.
- No public database access: RDS instances are deployed in private subnets with no public IP. Access is limited to the Agent and Orchestrator security groups.
- MCP connectors: Outbound connections to customer data sources (PostgreSQL, MySQL, S3, etc.) are governed by MCP policy enforcement before any data leaves the connector.
For In-VPC deployments, all traffic stays within the customer's AWS account. No data leaves the VPC boundary.
Secret management
Production deployments use AWS Secrets Manager for all credentials:
| Secret type | Storage | Rotation |
|---|---|---|
| Database passwords | AWS Secrets Manager | Supported via Secrets Manager rotation |
| LLM provider API keys | AWS Secrets Manager or database (AES-256-GCM encrypted) | Hot-reload every 60s from Secrets Manager |
| JWT signing keys | AWS Secrets Manager | Manual rotation with zero-downtime key rollover |
| License keys | Environment variable (Ed25519-signed, not sensitive) | Per-issuance |
LLM provider credentials stored in the database are encrypted at rest using AES-256-GCM with envelope encryption:
- A data encryption key (DEK) is generated from AWS KMS
- Credentials are encrypted with the DEK using AES-256-GCM
- The plaintext DEK is zeroed from memory after encryption
- Only the encrypted DEK and ciphertext are stored
Credentials are decrypted only at the moment of use and never written to logs.
Authentication
All customer data, policy, and control-plane API endpoints require authentication. Operational endpoints (/health, /metrics, /prometheus) and the Community SaaS self-registration bootstrap route are intentionally unauthenticated.
| Authentication method | Where used | Details |
|---|---|---|
| Basic Auth (client credentials) | SDK and API access | Authorization: Basic base64(clientId:clientSecret) where clientSecret is an Ed25519-signed license key |
| JWT user tokens | Request-scoped identity | Optional user_token field for human audit trail attribution |
| Admin API key | Customer portal administrative endpoints | Required in all environments. Stored in AWS Secrets Manager. |
| Session cookies | Customer portal UI | HTTP-only, secure, SameSite=Strict |
The Admin API key requirement was enforced across all environments — administrative endpoints are never callable without authentication.
Data handling
Data residency
| Deployment mode | Data location | Who controls |
|---|---|---|
| Self-hosted | Customer's infrastructure | Customer |
| In-VPC | Customer's AWS account | Customer |
| Community SaaS | us-east-1 (AWS) | AxonFlow |
Self-hosted and In-VPC deployments give customers full control over data residency. No telemetry, model calls, or customer data is sent to AxonFlow infrastructure in these modes.
Encryption
| Layer | Mechanism | Details |
|---|---|---|
| In transit (external) | TLS 1.3 | Terminated at ALB with ALPN h2 support |
| In transit (internal) | TLS | Service-to-service communication within VPC |
| At rest (database) | AES-256 | RDS encryption enabled by default |
| At rest (credentials) | AES-256-GCM | Envelope encryption via AWS KMS for stored LLM provider keys |
| At rest (audit logs) | AES-256 | Inherited from RDS encryption |
PII detection and redaction
AxonFlow's PII detection engine runs on governed LLM, gateway, and MCP paths, scanning for sensitive data patterns before they reach the model or leave the platform.
Detected PII types:
| Category | Patterns | Validation |
|---|---|---|
| Financial | Credit card numbers, IBAN, bank accounts | Luhn checksum (cards), MOD-97 (IBAN), ABA checksum (routing) |
| Identity (US) | SSN, bank accounts | Area/group/serial validation (SSN), ABA routing checksum (bank accounts) |
| Identity (India) | Aadhaar, PAN | Verhoeff checksum (Aadhaar), format validation (PAN) |
| Identity (Singapore) | NRIC, FIN, UEN | Format validation |
| Identity (EU) | IBAN, passport | MOD-97 (IBAN), format validation |
| Contact | Email, phone | RFC 5322 (email), international format (phone) |
| Personal | Date of birth | Multi-format date parsing |
| Travel | Booking reference, passport | Format validation |
Each detection type supports configurable enforcement:
| Action | Behavior |
|---|---|
block | Reject the request entirely |
redact | Replace detected PII with [REDACTED:type] placeholders |
warn | Allow the request but log a warning |
log | Allow silently, record in audit trail |
Separate action controls exist for different enforcement points: PII_ACTION (proxy mode), GATEWAY_PII_ACTION (gateway mode), MCP_PII_ACTION (MCP connectors).
SQL injection scanning
Every query processed by AxonFlow passes through SQL injection detection that identifies risky SQL patterns, including:
- Union-based injection
- Boolean-based blind injection
- Time-based blind injection
- Stacked queries
- Comment-based obfuscation
Enforcement is configurable via SQLI_ACTION (block, warn, or log).
Audit trail
The audit logging system records every policy decision with:
decision_id— unique identifier for the decisionverdict— allow, deny, redact, or require_approvalevaluated_policies— which policies were checked and their individual resultstimestamp— when the decision was madeidentity— org_id, client_id, and user_id (if provided)trace_id— W3C traceparent correlation for distributed tracing
Audit logs are captured at multiple layers:
| Layer | What is recorded |
|---|---|
| Agent | Gateway decisions, PII detections, SQLi detections, rate limit events |
| Orchestrator | LLM routing decisions, policy evaluations, provider selections |
| MCP | Connector access requests, response redactions, exfiltration checks |
| Workflow | Plan execution steps, HITL approval decisions, retry events |
Audit data is stored in RLS-protected tables — each organization can only query its own audit trail. Retention is configurable by deployment.
GDPR erasure
AxonFlow provides a POST /api/v1/gdpr/delete endpoint for Data Subject erasure requests. The endpoint removes all data associated with a specified identity across all platform tables within the authenticated organization's scope.
Evidence export
Evidence export (Evaluation and Enterprise tiers) provides structured exports of audit data, policy decisions, and governance evidence in formats suitable for compliance review. This includes decision chains, policy evaluation details, and temporal audit records.
Access control
Role-based access
The customer portal supports custom roles with org-scoped permissions. Role assignments control which portal users can view audit logs, manage policies, configure providers, or approve HITL requests.
SSO and SAML
Enterprise deployments support SAML-based SSO for customer portal authentication. This integrates with existing identity providers (Okta, Azure AD, Google Workspace) so portal users authenticate through the organization's standard identity flow.
SCIM provisioning
SCIM provisioning automates user lifecycle management — provisioning and deprovisioning portal users based on changes in the organization's identity provider. This prevents orphaned accounts when employees leave.
API key management
API keys are managed through the customer portal with org-scoped permissions. Each key is associated with a specific organization and inherits that organization's RLS boundary. Keys can be created, rotated, and revoked through the portal UI or the management API.
Engineering practices
Source-available code
AxonFlow is licensed under BSL 1.1 (Business Source License). The full platform source code is available for inspection. Security teams can:
- Audit the RLS implementation directly
- Review PII detection logic and validators
- Verify encryption and secret management code
- Inspect authentication and authorization flows
- Run the platform locally for security testing
This is not "trust us" — it is "read the code."
Supply chain security
| Practice | Details |
|---|---|
| Signed commits | DCO (Developer Certificate of Origin) sign-off on every commit |
| Container scanning | Trivy scans on every container image build |
| Static analysis | CodeQL analysis on every pull request |
| Dependency review | Automated dependency review on every PR |
| Module pinning | Go module checksums, npm lockfile integrity checks |
| Non-root containers | All production containers run as non-root users |
| Health checks | Docker HEALTHCHECK instructions on all service containers |
CI/CD security
| Practice | Details |
|---|---|
| Required status checks | All PRs must pass CI before merge |
| Merge queue | Sequential merge queue prevents race conditions |
| Branch protection | No force push to main. No direct commits. |
| OIDC publishing | PyPI and npm packages published via OIDC — no long-lived credentials |
| Provenance attestation | Published packages include build provenance |
Compliance capabilities
AxonFlow provides technical capabilities that help teams build compliant AI systems. The platform itself is not a certification body — it provides the runtime controls, audit infrastructure, and evidence that compliance programs require.
| Capability | RBI FREE-AI | SEBI AI/ML | EU AI Act | MAS FEAT | HIPAA | PCI-DSS |
|---|---|---|---|---|---|---|
| PII detection + redaction | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Region-specific validators (Aadhaar, PAN, NRIC, IBAN) | ✓ | ✓ | ✓ | ✓ | — | — |
| SQL injection scanning | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Audit trail + evidence export | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| HITL approval gates | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| Emergency circuit breaker | ✓ | — | ✓ | ✓ | — | — |
| Cost controls | ✓ | ✓ | — | — | — | — |
| MCP connector governance | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Decision Mode (PDP/PEP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Governance profiles | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Policy simulation | ✓ | ✓ | ✓ | ✓ | — | — |
✓ = capability directly addresses a requirement in this framework. — = not a primary requirement for this framework.
For framework-specific details, see the compliance overview and individual framework pages:
Certifications
AxonFlow does not currently hold SOC 2 or ISO 27001 certification. The platform is source-available under BSL 1.1, which means security teams can audit the implementation directly rather than relying on third-party attestation.
For organizations that require third-party certification as a procurement gate, self-hosted and In-VPC deployments inherit the customer's own certifications — AxonFlow runs as software within the customer's certified infrastructure.
Deployment security by mode
| Concern | Self-hosted | In-VPC | Community SaaS |
|---|---|---|---|
| Data residency | Customer-controlled | Customer's AWS | us-east-1 |
| Network isolation | Customer-controlled | VPC-scoped | Shared infrastructure with RLS isolation |
| Secret management | Customer-managed | Customer's AWS Secrets Manager | AxonFlow-managed |
| Encryption keys | Customer-managed | Customer's KMS | AxonFlow-managed |
| Container images | Customer-built from source | AxonFlow ECR | AxonFlow-managed |
| Audit log access | Direct database access | Direct database access | API + portal |
See deployment modes for the complete comparison.
Questions
For security questions, vulnerability reports, or procurement questionnaires, contact [email protected].
For a hands-on security review with access to the source code and a dedicated test environment, apply for the Design Partner Program.
