Security

1. Overview

Intended is built with security as a foundational requirement, not an afterthought. As an AI Authority Runtime that issues cryptographic authorization for AI agent actions, the integrity of our platform directly impacts the security posture of every customer. This document describes the security practices, infrastructure, and controls that protect the Intended platform and your data.

2. Infrastructure

• Cloud provider: Amazon Web Services (AWS), Intended's Authority Engine is deployed in the us-east-1 AWS region with multi-AZ redundancy within that region. Multi-region disaster recovery is on the product roadmap but not yet in production. For customers requiring multi-region resilience, contact sales@intended.so to discuss dedicated-instance or enhanced-infrastructure options.
• Network isolation: VPC with private subnets for application and database tiers. No direct internet access to backend services
• Encryption at rest: AES-256-GCM for all data at rest, including database volumes, object storage, and backups
• Encryption in transit: TLS 1.3 enforced for all connections — API traffic, database connections, cache connections, and internal service-to-service communication
• Storage: Encrypted EBS volumes for compute, encrypted S3 with Object Lock (Compliance mode) for long-term audit retention
• Secrets management: Signing keys and connector credentials encrypted with per-tenant AES-256-GCM keys. Secrets are never logged, exported, or stored in plaintext

3. Authentication and multi-factor authentication

• Session-based authentication for the Operator Console with secure, HTTP-only, same-site cookies
• API key authentication for programmatic access with hashed storage (keys are never stored in plaintext)
• API key prefixes (intended_live_, intended_test_) enable identification without exposing key material
• Brute-force protection with rate limiting on authentication endpoints and progressive lockout
• Automated session expiry with configurable timeout periods
• SSO/SAML integration available for Enterprise customers

3.1 Multi-factor authentication (MFA)

Intended requires multi-factor authentication (MFA) for the following Console portal roles: owner, billing_admin, admin, approver, and operator. MFA is also required for any Intended employee or operations staff with production access. Only the developer and viewer portal roles are exempt, and neither can mutate state or approve escalations. MFA is available and strongly recommended for all customer account holders; it is optional only for the exempt roles listed above. Enterprise customers can enforce MFA organization-wide via SAML/SSO configuration, which additionally extends MFA to the developer and viewer roles. Supported MFA methods: Time-based one-time password (TOTP) apps (Google Authenticator, Authy), SMS (SMS delivery from Intended), WebAuthn / FIDO2 keys (for Enterprise). Customers using Okta, Azure AD, or other enterprise identity providers can configure MFA at the identity provider level; MFA configuration flows to Intended via SAML/OIDC assertion.

4. Authorization and multi-tenant isolation

• Per-tenant isolation: Every database query is scoped to the authenticated tenant. No cross-tenant data access surface exists
• Role-based access control (RBAC) with four defined roles and twenty granular permissions, enforced at the middleware level
• Fail-closed authority decisions: When the Authority Engine cannot resolve a policy evaluation (missing data, ambiguous rules, system error), the default outcome is denial — never bypass
• Authority tokens are scoped to specific actions, targets, and expiry windows. Tokens cannot be used outside their defined scope
• Connector credentials are isolated per tenant with separate encryption keys

4.1 Multi-tenant isolation and residual risk

Intended implements multi-tenant isolation at the application layer via middleware authorization and query scoping. Specifically: Application-Layer Enforcement: Every database query is scoped to the authenticated tenant's ID. API handlers verify tenant authorization before returning data. Tenant isolation keys derived from account credentials. No single-tenant query can return cross-tenant data at application level. Residual Risk (Not Mitigated by Application-Layer Enforcement): Postgres row-level security (RLS) is NOT implemented. Database administrators (DBAs) with direct database access could theoretically query across tenant boundaries by circumventing application middleware. This risk is accepted and mitigated via: Least-privilege access: only 2 DBAs (on-call ops) have production database credentials. Comprehensive audit logging: all DBA queries logged and reviewed monthly. Incident response: any DBA access triggers audit and incident investigation. Access revocation: DBA credentials rotated monthly; revoked on termination. Customers Requiring Database-Layer Isolation: Customers subject to strict isolation requirements (HIPAA, FedRAMP, PCI DSS Level 1) should discuss dedicated-instance, enhanced-isolation, or database-per-tenant options with Intended. Contact security@intended.so to discuss.

5. Cryptography

• RSA-4096: Per-tenant key pairs for signing authority tokens. Private keys encrypted at rest with AES-256-GCM
• HMAC-SHA-256: Evidence bundle integrity verification. Bundles are verifiable without database access
• SHA-256: Hash chain for the immutable audit ledger. Each entry references the previous entry's hash, creating a tamper-evident chain
• HKDF (HMAC-based Key Derivation Function): Used for deriving scoped key material from master keys
• Single-use nonces: Every authority token contains a cryptographic nonce consumed on first verification. Replay attacks are structurally impossible
• Automated key rotation lifecycle: Keys transition through ACTIVE, PREVIOUS, and RETIRED states with overlap periods to ensure zero-downtime rotation

6. Audit trail integrity

• All authority decisions are recorded in an immutable, hash-chained audit ledger
• Each audit entry contains the decision outcome, intent metadata, risk scores, matched policies, token claims, and a SHA-256 hash linking it to the previous entry
• Audit records cannot be modified or deleted after creation — not by customers, not by Intended
• Tamper detection: Any modification to an audit entry breaks the hash chain, which is detectable by automated integrity checks and customer-initiated verification
• Cryptographic receipts: Every authority decision produces a signed receipt that can be independently verified
• Evidence bundles: HMAC-SHA-256 signed packages containing complete decision context, exportable and verifiable offline
• Long-term retention: Enterprise audit data stored in S3 Object Lock (Compliance mode) for immutable, regulatory-grade retention

7. Third-party runtime boundary

• Intended can govern customer-operated third-party runtimes, but it does not assume operational control of those runtimes unless expressly stated in a separate managed-service agreement
• For the OpenShell / NemoClaw reference integration, Intended currently compiles policy artifacts for customer review and deployment; it does not remotely administer the upstream runtime by default
• Customer remains responsible for upstream runtime hardening, credential management, endpoint review, and production rollout practices
• Where upstream software is identified as alpha, preview, or reference-only, Intended does not represent that the upstream software itself is production-ready
• Generated runtime policy artifacts should be reviewed and staged before production deployment because they can affect network reachability, tool scope, and execution boundaries

8. Penetration testing

• Intended conducts annual third-party penetration tests performed by independent security firms
• Testing scope includes the Authority Engine API, Operator Console, authentication and authorization systems, and infrastructure
• Findings are triaged by severity and remediated according to defined SLAs: critical within 24 hours, high within 7 days, medium within 30 days
• Executive summaries of penetration test results are available to Enterprise customers under NDA upon request

9. Responsible disclosure

Intended operates a responsible disclosure program for security researchers who discover vulnerabilities in our Services. If you discover a security vulnerability, please report it responsibly:

• Email: security@intended.so
• Include: a detailed description of the vulnerability, steps to reproduce, and any proof-of-concept code or screenshots
• Do not publicly disclose the vulnerability before Intended has had a reasonable opportunity to address it
• Intended commits to a 90-day disclosure timeline: we will acknowledge receipt within 2 business days, triage within 5 business days, and work to remediate within 90 days of the initial report
• We will not pursue legal action against researchers who report vulnerabilities in good faith and comply with this disclosure policy
• We will credit researchers (with permission) in our security acknowledgments

10. Bug bounty program

Intended is developing a formal bug bounty program to reward security researchers for responsibly disclosed vulnerabilities. The program will include defined scope, severity-based reward tiers, and clear rules of engagement. Until the formal program launches, please use the responsible disclosure process described in Section 8. Researchers who report valid vulnerabilities during this period will be retroactively eligible for rewards when the program launches. For updates, contact security@intended.so.

11. Compliance and certifications

• SOC 2 Type II: Audit in progress; expected completion in late 2026, subject to auditor availability, remediation timelines, and scope finalization. Refer to security@intended.so for current status and estimated availability. This is a target, not a binding commitment, and subject to change based on audit findings.
• GDPR: Intended processes data in accordance with the General Data Protection Regulation. Data Processing Agreement available for all customers
• CCPA/CPRA: Intended complies with the California Consumer Privacy Act and California Privacy Rights Act. We do not sell personal information
• Penetration testing: Annual third-party assessments with results available to Enterprise customers
• Encryption standards: NIST-approved algorithms (AES-256-GCM, RSA-4096, SHA-256, HMAC-SHA-256)
• Additional certifications (ISO 27001, HIPAA BAA, FedRAMP) are on the roadmap. Contact security@intended.so for the current status

12. Incident response and notification

Intended maintains a documented incident response plan with defined roles (Incident Commander, Engineering Lead, Legal, Communications) and escalation procedures. Notification Timelines: (a) Critical Incident (unauthorized access, confirmed data breach): Affected customers notified within 24 hours of confirmation. Initial notification: "Incident Confirmed" + Data scope (affected tables/tenants) + Mitigation status. (b) High Incident (attempted unauthorized access, suspicious activity): Notification within 72 hours of confirmation. Notification: "Incident Detected" + Investigation status + Interim protections applied. (c) Medium Incident (failed authentication, configuration issue): Notification within 5 business days. Summary of incident + impact + remediation. (d) Regulatory Notification (GDPR Art. 33, CCPA §1798.82): GDPR: Notification to supervisory authorities within 72 hours of discovery. CCPA: Notification to California Attorney General and affected consumers per CCPA timeline (without unreasonable delay). (e) Post-Incident Review (RCA): Preliminary RCA within 48 hours (incident timeline, initial findings). Full RCA within 5 business days (root cause, contributing factors, remediation, prevention). RCA shared with Enterprise customers and regulators (as requested). (f) Communication Channel: Incident notifications sent to Customer's designated security contact. Real-time incident status at status.intended.so. Enterprise customers may request real-time incident updates via support@intended.so.

13. Contact

For security-related inquiries, vulnerability reports, or to request security documentation, contact security@intended.so. Enterprise customers can also reach their dedicated account team for security reviews and compliance documentation.