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.
For procurement and security review, start with the Security Control Matrix. It lists the concrete security features and services AxonFlow provides before mapping them to compliance frameworks.
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. Public application traffic should use HTTPS.
- Internal service communication: Agent ↔ Orchestrator traffic stays within the private subnet. The default service-to-service path is plain HTTP inside the private network; customers that require internal TLS can add a service mesh or equivalent network control.
- 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, AxonFlow services, databases, policies, audit records, and connector configuration run in the customer's AWS account. Model/provider calls and connector egress follow the customer-approved network paths for that deployment.
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 when CONNECTOR_ENCRYPTION_KEY is configured:
- The deployment provides a connector encryption key through the environment or its secret-management layer
- Credentials are encrypted with AES-256-GCM before storage
- The encrypted credential payload is stored in the database
- Production deployments should source
CONNECTOR_ENCRYPTION_KEYfrom a managed secret store
If CONNECTOR_ENCRYPTION_KEY is not configured, development deployments can fall back to plaintext credential storage. Do not use that fallback for production. Credentials are decrypted only at the moment of use and should never be 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 for SaaS production admin routes; self-managed and local modes can configure the middleware differently. Store the key in a managed secret store. |
| Session cookies | Customer portal UI | HTTP-only, secure in production, SameSite=Lax |
Treat the Admin API key like a database credential or cloud root credential. It is for tightly scoped tenant lifecycle and license automation, not application runtime code.
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 control over data residency. Heartbeat telemetry can be disabled with AXONFLOW_TELEMETRY=off; customer content, policies, audit records, and connector data remain in the deployment unless the customer configures external model or connector paths.
Encryption
| Layer | Mechanism | Details |
|---|---|---|
| In transit (external) | TLS 1.3 | Terminated at ALB with ALPN h2 support |
| In transit (internal) | Private network controls by default | Service-to-service traffic stays inside the private deployment network; add service mesh or internal TLS where required |
| At rest (database) | AES-256 | RDS encryption enabled by default |
| At rest (credentials) | AES-256-GCM with configuration | Stored LLM provider credentials are encrypted when CONNECTOR_ENCRYPTION_KEY is configured |
| 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
For Community SaaS and plugin-tier tenants, AxonFlow exposes a two-step, email-verified tenant erasure flow:
POST /api/v1/tenant/{tenant_id}/delete-requestaccepts the email on file and returns the same generic202response whether the tenant/email pair matched or not.POST /api/v1/tenant/{tenant_id}/delete-confirmconsumes the single-use confirmation token and atomically removes the tenant registration, plugin license, audit logs, daily usage counters, and usage events.
Confirmation tokens expire after 1 hour, are stored as HMAC-SHA256 hashes, and can be hardened with AXONFLOW_TENANT_DELETE_TOKEN_PEPPER. Stripe customer archive is best-effort after the database deletion has committed; when a Pro license is still inside the 14-day refund window, the deletion log marks that manual refund follow-up is needed.
AxonFlow does not expose a generic POST /api/v1/gdpr/delete endpoint that deletes arbitrary customer-owned identities across external systems. For self-hosted or enterprise deployments, customer applications remain responsible for deleting source-system records while AxonFlow provides audit trails, PII controls, and deployment-specific evidence.
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 identity providers such as Okta, Microsoft Entra ID, Auth0, and other SAML 2.0 providers 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 can be assessed within the customer's own certified environment because AxonFlow runs as software inside that 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-managed secret store / KMS where configured | 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.
