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), deployed in US regions with multi-AZ redundancy
• 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

• 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 (mrt_live_, mrt_test_) enable identification without exposing key material
• Brute-force protection with rate limiting on authentication endpoints and progressive lockout
• Multi-factor authentication (MFA) support for all account holders
• Automated session expiry with configurable timeout periods
• SSO/SAML integration available for Enterprise customers

4. Authorization

• 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

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 Q3 2026. SOC 2 Type I report available upon request under NDA
• 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

• Intended maintains a documented incident response plan with defined roles, escalation procedures, and communication protocols
• Security incidents are classified by severity (Critical, High, Medium, Low) with corresponding response and resolution timeframes
• Affected customers are notified within 72 hours of a confirmed security incident involving their data
• Post-incident reviews are conducted for all Critical and High severity incidents, and lessons learned are incorporated into security controls

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.