IronbarkAML
Security · published 2026-04-25

How we run security.

Trust starts with how we handle data. This page is our public statement of how we run security today, with dates on every claim. We update it when reality changes, not when marketing wants a refresh.

Where your data lives

Customer data is hosted in Australia. Our database (Supabase Postgres) and our 7-year audit log (AWS S3 with Object Lock Compliance Mode) both run in the AWS Sydney region (ap-southeast-2). Backend compute is migrating from Singapore to AWS Sydney during Phase 2 of our build (ADR-005, locked 2026-04-24).

Disaster recovery replication target is Melbourne (ap-southeast-4). Data does not leave Australia.

How your data is protected

All data in transit uses TLS 1.3 via Cloudflare. All data at rest is encrypted with AES-256-GCM. Our key management uses AWS KMS, which is backed by FIPS 140-3 Security Level 3 validated hardware security modules in every AWS Region including Sydney.

Customer-managed encryption keys (BYOK) are available at Phase 4 enterprise tier. AWS KMS External Key Store (XKS), where keys never leave the customer's HSM, is available at Phase 6 on customer pull.

How tenants are isolated

We use Postgres Row-Level Security on every tenant-bearing table. Each row in scans, scan_results, cases, case_events, credits_ledger, monitoring_subscriptions, webhook_deliveries, and jobs carries an organisation_id column with a policy that filters on the JWT org_id claim.

Architecture decisions ADR-001 (Trust Score), ADR-003 (Tenant Isolation), and ADR-004 (RBAC + Audit Log) publish the design.

How access is controlled

Every API call uses OAuth 2.0 client credentials with scoped tokens (scans:read, scans:write, cases:read, cases:write, reports:read, monitoring:write, batch:write). API key expiry warnings ship in every response header (X-ApiKey-Expires-In) at 30-day, 7-day, and 24-hour thresholds.

Multi-factor authentication is enforced for administrative access. Our role model uses 4 default roles (Principal, Senior, Member, Auditor) across 16 permissions, totalling 64 explicit role-permission bindings (ADR-004).

How code reaches production

Every pull request runs static analysis (GitHub CodeQL, with Semgrep Pro added at Phase 3) and dependency vulnerability scanning (Dependabot + pip-audit). Critical CVEs block merge. All container images run as non-root users.

The Evaluator smart contract is reviewed internally before any testnet deployment, and will undergo external audit (Sherlock, Code4rena, or Trail of Bits class) before any mainnet USDC handling.

How we respond to incidents

Our incident response plan follows NIST SP 800-61 Revision 3 (April 2025), aligned to NIST Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). Severity levels P0 to P3 are documented. We commit to the Australian Notifiable Data Breaches scheme: assessment within 30 days of becoming aware, notification to OAIC and affected individuals as soon as practicable once an eligible breach is confirmed.

Sub-processors

A current list of every third party that processes customer data sits at /security/subprocessors. We update this page within 30 days of any change.

AI governance

Which AI models we use, what data they see, whether your data trains them (it does not), and how to opt out is published at /security/ai. Updated within 30 days of any change.

MCP server

If you call Ironbark from your own agent over the Model Context Protocol, how that surface is authenticated, gated, billed, and audited is published at /security/mcp.

Vulnerability disclosure

Found something? Email security@ironbarkaml.com.au or reach us via /.well-known/security.txt. We commit to acknowledge within 2 business days, triage within 5 business days, and credit you (with consent) on /security/disclosure after fix.

What is coming

SOC 2 Type I and ISO 27001 Stage 1 readiness work begins when we accept our first enterprise pilot. SOC 2 Type II and ISO 27001 certification land at Phase 5 alongside the bug bounty program. IRAP assessment is on the table when we serve our first Australian Government customer.

The roadmap with phase-trigger-revenue triggers lives at /security/roadmap.

Why we publish all this

Published beats proprietary. Every weight in the Trust Score, every sub-processor, every certification window, every gap is a fact you can audit. That is the only business model we will run.

The act of publishing forces every claim to be evidenced. It is the forcing function we choose against marketing drift.

Last reviewed: 2026-04-25.

Next review: 2026-07-25.

Operator: IRONBARKTECH (ABN 29659123086).

Source policies and control library (public, CC BY 4.0): ironbark-portfolio-policies