Security & trust
Gamut governs your most sensitive AI risk and evidence, so security is a design property of the platform, not a feature bolted on. Trust is the product. This page sets out how Gamut is built to protect your data and how we hold ourselves accountable for it.
Security at a glance
Section titled “Security at a glance”| Area | What Gamut does |
|---|---|
| Tenant isolation | Each organisation’s data lives in its own database schema, with row-level tenant context checks and fail-closed enforcement on protected data paths. |
| Encryption | Sensitive secrets are protected with authenticated AES-256-GCM encryption at rest; all traffic is encrypted in transit over HTTPS with HSTS in production. |
| Access | Multi-factor authentication, step-up MFA for sensitive changes, single sign-on (OpenID Connect), role-based access and entitlement dual-gating. |
| Agentic AI | Zero-trust: agents hold no credentials, exact Runtime Access Policies require controlled approval, and every action is revalidated and enforced through Gateway, fail-closed. |
| AI handling | Model provider keys never reach the browser; all AI calls are governed server-side. |
| Accountability | Audited state changes and tamper-evident runtime evidence for governed agent actions. |
| Application hardening | Rate limiting, CSRF protection, content security policy and other production browser-hardening headers. |
| Assurance | Continuous security review, including dependency, static and authorised dynamic testing, with results assessed as part of release readiness. |
Tenant isolation
Section titled “Tenant isolation”Each organisation operates in its own tenant, and isolation is enforced at the data layer: each tenant’s records live in their own database schema, not merely filtered by an application query. One organisation’s AI systems, assessments, evidence and users are kept strictly separate from every other, and access is always scoped to the tenant a user belongs to. Protected data paths also bind tenant context and fail closed when that context cannot be verified.
Encryption
Section titled “Encryption”Sensitive secrets and credentials are protected with AES-256-GCM, an authenticated cipher, so stored secrets cannot be silently read or altered. The platform will not run in production without its encryption key, so secrets are never stored in plaintext. Passwords are stored as salted, one-way scrypt hashes and are never recoverable. All traffic is encrypted in transit over HTTPS, with HSTS enforced.
Authentication and access
Section titled “Authentication and access”People sign in with a password or via single sign-on using OpenID Connect, so organisations can apply their own multi-factor and conditional-access policies. Gamut also supports its own multi-factor authentication, with step-up verification required before security-sensitive changes.
Access is governed by role-based access control and plan entitlements: a sensitive capability requires both the role permission and the plan entitlement, enforced server-side on every action. Administrators are deliberately not exempt from entitlement checks. Suspending a user or tenant revokes access immediately. Browser sessions carry CSRF protection, programmatic access uses named, revocable API tokens, and responses carry modern browser-hardening headers including a strict content-security policy. Production also applies rate limiting and HSTS.
API tokens are bound to an accessible workspace, limited to read-only or read/write scope and time-bounded. Creating write authority requires reauthentication, and account-security events invalidate existing sessions and programmatic credentials where continued access would no longer be appropriate.
Zero-trust agentic AI
Section titled “Zero-trust agentic AI”Gamut governs AI that takes action, not just AI that answers questions, and it does so on a zero-trust basis. Agents never hold credentials and never call tools directly. Every agent action passes through Gamut Gateway, where policy is enforced and provider keys live, and the execution layer (Claw) redacts sensitive values before any output leaves it. Enforcement is fail-closed: if a decision cannot be made or verified safely, the action does not proceed. See the agentic stack overview.
Runtime Access Policies bind authority to an exact agent, governed connection, action, resource, data class, environment and time boundary. Policy creation and policy approval are separated. Immediately before execution, Gateway confirms that the policy, approval and request context remain current and refuses stale, changed, expired or replayed authority.
Governed, server-side AI
Section titled “Governed, server-side AI”All AI analysis is proxied server-side. Model provider keys are never exposed to the browser, and prompts and responses are handled by Gamut rather than sent directly from a user’s device to a model provider. This keeps model usage governed and credentials protected.
What is sent depends on the feature:
- Framework AI Assist, full context: selected system or agent scope, the relevant assessment item, structured scores/statuses and the authorised notes, evidence metadata and routing context required for that analysis.
- Framework AI Assist, scores-only privacy mode: direct identifiers and free-text context are excluded; the model receives the minimum structured assessment and route signals required for the bounded task.
- AI Consultant: permitted workspace records and free text shown by the on-screen context manifest. Scores-only privacy mode does not narrow Consultant context.
- Generated narratives: use the context described on the generating screen; review the scope before submitting.
AI output remains advisory. It cannot approve scope, applicability, evidence, risk acceptance, policy or the human assessment conclusion. Avoid entering secrets and unnecessary personal data, and apply the configured model provider’s contractual and organisational handling requirements.
Accountability by default
Section titled “Accountability by default”State-changing actions are recorded in an audit log, and governed agent actions generate tamper-evident runtime evidence. Together these provide a reviewable record of relevant human and agent activity for the configured scope and retention period.
Our security practice
Section titled “Our security practice”Security is part of how we build, not an afterthought:
- Secure by construction. The controls above are architectural, isolation, least privilege, fail-closed enforcement and encrypted secrets are properties of the design.
- Continuous security review. We conduct regular security review, including static analysis and authorised dynamic testing, as part of our release process.
- Least surface area. Gamut runs on a deliberately minimal dependency footprint to reduce supply-chain and attack surface.
- Dependency hygiene. Dependencies are reviewed as part of release readiness. A point-in-time scan is evidence for that release, not a permanent guarantee; newly disclosed issues are assessed and treated according to risk.
Independent validation
Section titled “Independent validation”We are committed to validating our security posture independently, not just asserting it. We are commissioning independent third-party penetration testing and pursuing recognised certifications (such as SOC 2 and ISO/IEC 42001) as we scale. Organisations evaluating Gamut can request our current security overview through their account contact.
Reporting a vulnerability
Section titled “Reporting a vulnerability”We welcome reports from security researchers and customers. If you believe you have found a security issue, please see our vulnerability disclosure policy for how to report it safely and what to expect from us.
- Vulnerability disclosure: how to report an issue.
- Agentic stack overview: zero-trust governance of agents.
- Workspaces & tenancy: isolation between organisations.