Security & Compliance Guide

This guide details the security architecture and compliance posture of the Operanix platform. It covers network security, tenant isolation, data protection, access controls, and regulatory compliance frameworks.

Security is not an add-on in Operanix. Every feature is designed with security and compliance as foundational requirements, not afterthoughts. This document describes controls that are always active for all tenants.

SSRF Protection

Server-Side Request Forgery (SSRF) is a critical attack vector in platforms that make outbound HTTP requests on behalf of users. Operanix implements multi-layer SSRF protection.

Protection Layers

IP blocklist — All outbound requests from workflows and knowledge crawlers are checked against a blocklist of internal IP ranges. Blocked ranges include 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 (link-local), and ::1 (IPv6 loopback).
DNS resolution validation — After DNS resolution, the resolved IP is checked against the blocklist before the connection is established. This prevents DNS rebinding attacks where a hostname initially resolves to a public IP and then resolves to an internal IP.
Protocol restriction — Only http:// and https:// protocols are permitted. File, FTP, gopher, and other protocol schemes are blocked.
Redirect following — HTTP redirects are limited to 3 hops maximum. Each redirect target is re-validated against the IP blocklist and protocol restrictions.
Cloud metadata blocking — Requests to cloud provider metadata endpoints (169.254.169.254, metadata.google.internal) are explicitly blocked to prevent credential theft.

// SSRF protection configuration (enforced globally, not configurable per tenant)
{
  "ssrf_protection": {
    "blocked_ip_ranges": [
      "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16",
      "127.0.0.0/8", "169.254.0.0/16", "::1/128"
    ],
    "blocked_hosts": ["metadata.google.internal", "169.254.169.254"],
    "allowed_protocols": ["http", "https"],
    "max_redirects": 3,
    "dns_rebind_protection": true,
    "timeout_ms": 10000
  }
}

Tenant Isolation

Operanix is a multi-tenant platform with strict isolation guarantees. No tenant can access another tenant's data, configurations, or resources.

Isolation Boundaries

Data isolation — All data is stored with a tenantId partition key. Database queries are scoped to the requesting tenant at the query layer, not just the application layer. Firestore security rules enforce tenant boundaries independently of application code.
Compute isolation — Workflow executions, knowledge pipeline runs, and agent inference requests run in tenant-scoped execution contexts. Resource limits (CPU, memory, execution time) are enforced per tenant.
Network isolation — Tenant API keys and OAuth tokens are stored in tenant-scoped credential vaults. One tenant's credentials cannot be used by another tenant's workflows.
Search index isolation — Vector search indices are partitioned by tenant. Similarity searches never cross tenant boundaries.
Audit isolation — Each tenant's audit trail is logically isolated. Platform administrators cannot view tenant audit logs without explicit tenant authorization.

Tenant isolation is enforced at multiple layers (application, database, infrastructure). A failure at one layer does not compromise isolation because the other layers independently enforce boundaries.

Compliance Gate

The compliance gate is a mandatory checkpoint in the knowledge pipeline and agent deployment process. See the Knowledge Operations Guide and Governance Guide for detailed coverage.

Gate Enforcement Points

Checkpoint	What is Checked	Failure Action
Knowledge publish	PII scan, sensitivity classification, source verification, freshness	Block publication, route to compliance queue
Agent deployment	Evaluation scores, safety gate configuration, approval chain completion	Block deployment, generate remediation report
Workflow activation	External connection security, data scope validation, permission check	Block activation, require security review
Configuration change	Impact assessment, approval chain, change documentation	Block change, escalate to governance admin

PII Detection

Operanix runs PII detection at multiple points in the data lifecycle to prevent inadvertent exposure of personally identifiable information.

Detection Methods

Pattern matching — Regex-based detection for structured PII: email addresses, phone numbers (international formats), SSNs, credit card numbers (with Luhn validation), passport numbers, and driver's license numbers.
NER model — A fine-tuned named entity recognition model detects unstructured PII: full names, physical addresses, dates of birth, medical record numbers, and financial account identifiers.
Custom patterns — Tenants can define custom PII patterns for industry-specific identifiers (employee IDs, patient numbers, policy numbers).
Contextual detection — The system considers surrounding context to reduce false positives. For example, "call 1-800-555-0199" is detected as a business phone number (not PII), while "John's number is 555-0199" is flagged as personal PII.

Detection Points

Point	Direction	Action on Detection
Knowledge ingestion	Inbound	Flag for review, block publication until resolved
Agent response	Outbound	Redact PII, log safety gate trigger
Workflow data	Both	Mask in logs, block if policy prohibits
User input	Inbound	Warn agent not to repeat PII in response
Audit export	Outbound	Redact PII in exported logs unless compliance officer overrides

Role-Based Access Control (RBAC)

Operanix implements RBAC with 8 predefined roles. For detailed role descriptions, see the Governance Guide.

Permission Categories

Category	Permissions
Agents	Create, read, update, delete, deploy, retire, configure knowledge, manage schedule
Knowledge	Add sources, review content, approve/reject, publish, rollback, manage pipeline
Governance	Manage policies, configure safety gates, review approvals, manage RBAC, export compliance
Workflows	Create, edit, activate, deactivate, manage connections, set permissions
Analytics	View dashboards, export reports, configure alerts
Platform	Billing, tenant settings, user management, API key management

Access Control Features

Separation of duties — Enforced restrictions prevent the same user from holding conflicting roles (e.g., Agent Manager and sole Compliance Officer).
Least privilege — Users are granted the minimum permissions required for their function. The Viewer role provides read-only access with no operational capabilities.
Time-limited access — Grant temporary elevated permissions with automatic expiration. Useful for consultants, auditors, and temporary team members.
MFA enforcement — Multi-factor authentication can be required for specific roles or all users. Supports TOTP, WebAuthn/FIDO2, and SMS.
Session management — Configurable session timeout (default: 8 hours), idle timeout (default: 30 minutes), and concurrent session limits.

Immutable Audit Trail

Every action in Operanix is recorded in an append-only, cryptographically chained audit log.

Audit Record Structure

{
  "id": "audit-2026-06-15-a7f3b2c1",
  "timestamp": "2026-06-15T14:23:07.892Z",
  "tenant_id": "tenant-acme-corp",
  "actor": {
    "user_id": "user-jane-smith",
    "email": "jane@acme.com",
    "role": "agent_manager",
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0..."
  },
  "action": "agent.deploy",
  "resource": {
    "type": "agent",
    "id": "agent-customer-support",
    "name": "Customer Support Agent"
  },
  "details": {
    "version": "v3.2",
    "evaluation_score": 0.89,
    "approval_chain": "approved",
    "previous_version": "v3.1"
  },
  "hash": "sha256:a1b2c3...",
  "previous_hash": "sha256:x9y8z7..."
}

Immutability Guarantees

Append-only storage — Audit entries can only be created, never modified or deleted. This is enforced at the database level with write-only IAM permissions on the audit collection.
Cryptographic chaining — Each audit entry includes a SHA-256 hash of its content and the hash of the previous entry. Tampering with any entry breaks the chain, which is detected by integrity verification.
Regular integrity checks — Automated daily verification confirms the hash chain is intact. Any break triggers an immediate security alert.
External backup — Audit logs are replicated to a separate storage system with independent access controls. Even a full compromise of the primary system cannot alter the backup audit trail.

Rate Limiting

Operanix implements rate limiting at multiple levels to prevent abuse and ensure fair resource allocation.

Endpoint	Limit	Window	Response
API (authenticated)	1,000 requests	1 minute	429 Too Many Requests
API (unauthenticated)	60 requests	1 minute	429 Too Many Requests
Authentication	10 attempts	15 minutes	Account lockout (30 min)
Knowledge crawl	10 pages/second	Per source	Throttle and queue
Workflow execution	Per quota config	24 hours	Queue or reject
Agent inference	100 requests	1 minute	429 with retry-after

Encryption

In Transit

All traffic encrypted with TLS 1.3 (minimum TLS 1.2).
HSTS headers enforced with 1-year max-age and includeSubDomains.
Certificate transparency logging enabled.
Internal service-to-service communication uses mTLS.

At Rest

All data encrypted at rest using AES-256-GCM.
Encryption keys managed via Google Cloud KMS with automatic rotation (90-day cycle).
Customer-managed encryption keys (CMEK) available on Enterprise plans.
Credential vault uses envelope encryption with per-tenant data encryption keys.

SOC 2 Readiness

Operanix is designed to meet SOC 2 Type II requirements across all five trust service criteria.

Trust Service Criteria Coverage

Criteria	Operanix Controls
Security	RBAC, MFA, encryption, network controls, vulnerability management, incident response
Availability	Multi-region deployment, auto-scaling, health monitoring, disaster recovery plan
Processing Integrity	Input validation, data quality checks, pipeline verification, error handling
Confidentiality	Tenant isolation, data classification, access controls, encryption, secure disposal
Privacy	PII detection, consent management, data retention policies, DSAR handling

HIPAA Readiness

For healthcare organizations, Operanix provides HIPAA-compliant configurations.

Technical Safeguards

Access control — Unique user identification, emergency access procedures, automatic logoff, encryption/decryption of ePHI.
Audit controls — Immutable audit trail records all access to and modifications of ePHI-containing knowledge.
Integrity controls — Cryptographic hashing verifies that ePHI has not been improperly altered or destroyed.
Transmission security — TLS 1.3 encryption for all data in transit. No ePHI transmitted over unencrypted channels.

Administrative Safeguards

Business Associate Agreement (BAA) available for Enterprise plans.
Designated security officer role with compliance dashboard access.
Workforce training tracking for HIPAA-aware agent operators.
Contingency planning with documented backup and disaster recovery procedures.

HIPAA mode must be explicitly enabled for your tenant. When enabled, additional restrictions apply: all PII detection is set to maximum sensitivity, audit retention is set to 6 years minimum, and BAA must be executed.

GDPR Compliance

Operanix supports GDPR compliance with built-in tools for data protection, consent management, and data subject rights.

Data Subject Rights

Right	Operanix Support
Right of access	Data export tool generates a complete package of all data held for a data subject
Right to rectification	Knowledge editor tools allow correction of inaccurate personal data
Right to erasure	Data deletion workflow removes personal data from knowledge base, audit logs (with legal hold exception), and agent memory
Right to restrict processing	Processing restriction flags prevent specific data from being used in agent responses while retaining the data
Right to data portability	Export all personal data in machine-readable JSON format
Right to object	Opt-out mechanisms for automated decision-making with human review routing

Consent Management

Configurable consent collection for different processing purposes.
Consent records stored with timestamp, purpose, and granularity.
Consent withdrawal immediately stops processing for the specified purpose.
Cookie consent banner with granular category controls (analytics, marketing, functional).

Data Retention

Operanix provides configurable data retention policies with automated enforcement.

Data Type	Default Retention	Configurable Range
Conversations	90 days	30 days – 7 years
Knowledge base	Until manually deleted	90 days – indefinite
Audit logs	7 years	1 year – indefinite
User activity logs	1 year	90 days – 7 years
Workflow run data	90 days	30 days – 2 years
Evaluation results	1 year	90 days – indefinite
Backup data	30 days after source deletion	7 days – 90 days

Data retention policies run daily at 02:00 UTC. Data past its retention date is permanently deleted with cryptographic erasure verification. Deletion events are recorded in the audit trail.

Incident Response

Operanix maintains a documented incident response plan with defined severity levels and response procedures.

Severity Levels

Severity	Definition	Response Time	Notification
P0 — Critical	Data breach, complete service outage, active exploitation	15 minutes	Immediate: all affected tenants + executive team
P1 — High	Partial outage, data exposure risk, security vulnerability	1 hour	Within 1 hour: affected tenants + security team
P2 — Medium	Degraded performance, non-critical security finding	4 hours	Within 24 hours: affected tenants
P3 — Low	Minor issue, no data or security impact	24 hours	Next business day: status page update

Response Procedures

Detection — Automated monitoring detects anomalies in error rates, latency, authentication patterns, and data access patterns. Safety gate triggers above threshold automatically escalate.
Containment — Affected systems are isolated. For data breaches, affected tenant data access is immediately restricted while investigation proceeds.
Investigation — Root cause analysis using the immutable audit trail, system logs, and infrastructure metrics. Timeline reconstruction for affected resources.
Remediation — Fix deployed and verified. Affected data identified and secured. Credentials rotated if compromised.
Notification — Affected customers notified per the timeline above and per regulatory requirements (72 hours for GDPR, state-specific breach notification laws).
Post-mortem — Blameless post-mortem published within 5 business days. Corrective actions tracked to completion.

Operanix conducts quarterly tabletop exercises simulating security incidents. Results are documented and used to improve response procedures. Enterprise customers can participate in joint exercises.

Security Best Practices

Enable MFA for all users, not just administrators. Enforce it at the tenant level.
Review RBAC assignments quarterly. Remove access for departed employees immediately.
Set data retention policies before ingesting sensitive data. Retroactive policy changes do not delete data already past the new retention period.
Use the compliance export tool to generate evidence packages before audits, not during them.
Monitor the audit trail for unusual patterns: off-hours access, bulk data exports, privilege escalation attempts.
Keep tool connections minimal. Disconnect integrations that are no longer in use.
Subscribe to the Operanix security advisory mailing list for timely notification of security updates.