Identity and access
TOTP multi-factor authentication, recovery codes, secure session handling, authentication stamps, role-based capabilities, account lockout and server-side organisation/project access checks.
Included security baseline
Tenant isolation
Explicit organisation scope throughout application services, generic not-found behaviour for unauthorised tenant resources, private artefact resolution and PostgreSQL row-level-security policies with cross-tenant regression coverage.
Request hardening
CSRF protection, bounded request sizes, application-level rate limiting on public authentication/integration POST surfaces, secure cookies, HSTS on secure deployments, browser security headers and restrictive permissions policy.
Integration boundaries
Outbound-first connector design, constrained credential namespaces, approved destinations, redirect rejection, bounded responses, sanitised upstream errors, explicit tenant context and fail-closed automated telemetry where implemented.
Evidence and audit
Audit events, intervention history, discovery observations, automated-checkpoint provenance, correlation IDs and structured logs retain decision and control evidence.
Recovery
PostgreSQL point-in-time recovery and Blob version/soft-delete recovery are documented and exercised as part of the operating model.
Secure delivery
GitHub Actions exercises application/PostgreSQL tests plus dependency auditing, Bandit static analysis, reviewed-exception drift checking, repository-history secret scanning and reproducible CycloneDX SBOM generation.
Release integrity
Immutable release ZIPs and SBOMs are covered by SHA-256 integrity evidence. Promotion verifies the exact published artefacts and running application version rather than rebuilding arbitrary source during deployment.
Data protection
Azure-managed encryption, private Blob containers, HTTPS/TLS transport and runtime-only production configuration support the standard SaaS deployment. Secrets are not committed to source control.
Browser policy
A minimal Content Security Policy is enforced and a stricter policy is emitted in report-only mode while compatibility is assessed before full enforcement.
Tenant RLS status
PostgreSQL row-level-security policies are installed and tested across protected AIDE Chain, Blueprint and Mission tenant data. AIDE carries the active organisation into database transactions and the policies protect both row visibility and cross-tenant mutation. The planned production hardening step is to move the live application to a non-owner, least-privilege database identity so RLS becomes an independent database-enforced tenant boundary in addition to the existing server-side application controls.
Optional / planned enterprise uplift
The defence-in-depth roadmap includes Key Vault-backed secret references, managed-identity improvements, a non-owner PostgreSQL runtime identity, private PostgreSQL networking, GitHub-to-Azure OIDC deployment authentication, enforced stricter CSP, WAF/source-network/mTLS controls for deliberately exposed inbound integrations, network-level connector egress restrictions, external penetration testing, SIEM/SOC integration, dedicated environments, enhanced retention and external identity-provider integration.
ISO/IEC 27001 and SOC 2
AIDE's implemented technical controls already produce evidence that can support an information security management system and a SOC 2 control environment. External assurance requires more than secure software, however: policies, risk assessment and treatment, control ownership, access reviews, supplier governance, incident/continuity exercises, internal audit/management review and retained recurring evidence must operate as part of the organisation.
Assurance boundary
AIDE Chain is not currently claiming ISO/IEC 27001 certification or a SOC 2 Type II report. The Assurance Readiness page separates implemented technical evidence from the remaining management-system and independent audit/attestation work.