Built on a Foundation of Security
Entitle is architected as a policy processor, not a data processor. We evaluate decisions—we never touch your customer data or business logic.
Core Security Principle
Entitle is a Policy Decision Platform (PDP). We answer one question: "Is this capability allowed for this principal right now?" We evaluate policy—we never store, process, or access your customer data, business logic, or PII.
Architectural Consequence: Because we're not in your data path, we can't leak what we don't have. No customer records. No payment data. No business analytics. Only pseudonymous identifiers and policy metadata.
Hard Multi-Tenancy & Isolation
Entitle enforces hard tenant isolation at every layer. Cross-tenant access is architecturally impossible, not just policy-prevented.
Authentication-Based Tenancy
Tenant identity derived from authentication credentials (API key), never from request payload. One API key = one tenant per environment. No cross-tenant keys.
Row-Level Security
Database enforces tenant filters at the row level using RLS policies. Even with SQL injection, cross-tenant reads are impossible.
No Shared Resources
No shared API keys, no tenant-switching logic, no "super-admin" bypass. Tenant context is immutable for the request lifecycle.
GDPR-Compliant by Design
Entitle's architecture makes GDPR compliance straightforward because we don't process personal data. No PII means no GDPR data subject requests for Entitle.
Pseudonymous by Default
We work with identifiers like tenant-abc, user-123, or
org-xyz. We never require or store names, emails, or other PII.
Data Minimization
We only store what's required for policy evaluation: principal identifiers, capability names, and decision outcomes. Nothing more.
Retention Limits
Decision logs retained for 90 days for audit and debugging purposes, then purged. Policies retained until explicitly deleted by tenant.
No Third-Party Sharing
Entitle does not share tenant data with third parties. No analytics providers, no advertising networks, no data brokers.
Data Handling: What We Store vs. Never Store
Clear boundaries around what Entitle processes. This is not just policy—it's architectural.
✅ What We Store
- Policy definitions: Rules about which plans allow which capabilities
- Pseudonymous identifiers:
tenant-abc,user-123(no PII) - Capability identifiers:
export-data,premium-analytics - Decision logs: Principal X requested capability Y, result was allow/deny
- Optional context: Environment (prod/staging), region (if provided)
- Policy versions: Immutable policy history for rollback and audit
❌ What We Never Store
- Personal information: User emails, names, addresses, phone numbers
- Business data: Customer records, transaction details, analytics data
- Payment data: Credit cards, billing information, invoice details
- User behavior: Click streams, usage patterns, session tracking
- Feature content: What features actually do or how they're implemented
- Domain logic: Your business rules or proprietary workflows
Principle: Policy Processor, Not Data Processor
Entitle evaluates "Can principal X access capability Y?"—we never need to know who X is as a human, what Y does, or what data might be involved. This architectural boundary is fundamental to our security model.
Authentication & Authorization Model
MVP: API Key-Based Authentication
In the MVP, authentication uses per-tenant, per-environment API keys. Each tenant receives unique keys for dev, staging, and production environments.
Key Characteristics
- One key per tenant per environment - No shared credentials
- Tenant identity derived from key - Never from request payload
- Rotation supported - Generate new keys without downtime
- Scoped access - Keys grant access only to tenant's own policies
Roadmap: mTLS Certificate Authentication
Post-MVP, we'll support mutual TLS (mTLS) for enterprise deployments. This enables certificate-based authentication with automatic rotation and hardware security module (HSM) support.
Infrastructure & Network Security
TLS 1.3 Everywhere
All API traffic encrypted in transit using TLS 1.3. No unencrypted connections accepted. Certificate validation enforced.
API Endpoint Security
Rate limiting, DDoS protection, and request validation at the edge. Malformed requests rejected before reaching application logic.
Fail-Closed by Default
If policy cannot be evaluated due to errors, Entitle returns deny
by default. No fail-open modes that could grant unintended access.
Database Security
Encrypted at rest (AES-256). Row-level security enforces tenant isolation. Automated backups with point-in-time recovery.
Decision Logging & Audit Trail
All policy evaluation requests are logged with structured metadata for audit and debugging purposes.
What's Logged
- Timestamp (UTC)
- Tenant identifier
- Principal identifier (pseudonymous)
- Capability requested
- Decision outcome (allow/deny)
- Policy version applied
- Optional context metadata
Audit Query API
Roadmap
v1.1+ will provide query APIs allowing tenants to retrieve their own decision logs for compliance reporting, security analysis, and debugging. Queries scoped to tenant—no cross-tenant visibility.
Operational Security Practices
Development & Deployment
- All code changes reviewed before merge
- Automated testing including security regression tests
- Immutable infrastructure (no manual server changes)
- Secrets managed via dedicated secret manager (never in code)
Monitoring & Incident Response
- 24/7 uptime monitoring and alerting
- Automated anomaly detection for suspicious patterns
- Incident response plan with defined escalation paths
- Post-incident reviews for continuous improvement
Access Controls
- Principle of least privilege for all team access
- Multi-factor authentication required for all production access
- Audit logging of all administrative actions
- Regular access reviews and permission audits
What Entitle is NOT (Setting Boundaries)
Clarity on what we deliberately don't do is as important as what we do:
Not a Data Processor
We never handle, store, or access your customer business data, analytics, or transactions.
Not a Billing System
We don't process payments, store credit cards, or manage invoices. Stripe/Chargebee remain yours.
Not an Enforcement Engine
We evaluate decisions—your application enforces them. We never execute workflows or control features.
Not User Authentication
We assume authentication happens upstream (Auth0, Cognito, etc.). We evaluate post-auth authorization.
Not Usage Metering
We don't count API calls, track usage limits, or monitor consumption (deferred to v1.1+).
Not Feature Flag Infrastructure
We're policy-driven, not feature-flag driven. Use LaunchDarkly/Split for feature flags.
Compliance Status & Roadmap
Entitle is in controlled alpha. We're architecting for compliance from day one, but formal certifications come post-general availability.
Current Status
- GDPR-compliant by design (no PII processing)
- Security best practices implemented (encryption, isolation, audit logs)
- Incident response plan documented
- Data retention policies defined
Certification Roadmap
Post-MVP
- SOC 2 Type II: Targeted for 6-9 months post-GA
- ISO 27001: Under evaluation based on customer demand
- HIPAA BAA: Not planned for v1.0 (healthcare use cases deferred)
Alpha Transparency: We don't yet hold formal certifications. If your organization requires SOC 2 or ISO 27001 attestation for vendor onboarding, please discuss your timeline during alpha access request. We can prioritize certification based on customer need.
Security Questions?
We're committed to transparency. If you have specific security, compliance, or architecture questions, we'll answer them directly during your alpha evaluation.