Home / Trust & Legal / Security Architecture

Security Architecture & Controls

Architectural controls, cryptographic safeguards, tenant boundaries, and fail-closed runtime enforcement in InvisibleAct.

Version: 1.0.0
|
Effective Date: September 2026
|
Status: Active
|
Architecture: Pre-Execution Gatekeeper

1. Executive Summary

InvisibleAct provides runtime authorization and policy enforcement for autonomous AI agents. The platform acts as an authoritative, fail-closed gatekeeper that evaluates proposed agent actions against customer policies before tools or operations execute.

This document describes the architectural controls, authentication mechanisms, isolation boundaries, and security safeguards currently implemented in the InvisibleAct software.

2. Pre-Execution Runtime Authorization Architecture

InvisibleAct sits between autonomous AI agent decision-making loops and real-world tools, external APIs, and sensitive internal actions. 

                      +---------------------------------------+
                      |           AI Agent Runtime            |
                      |  (LangChain, CrewAI, AutoGen, MCP)    |
                      +---------------------------------------+
                                          |
                                          | Proposed Action Metadata
                                          v
                      +---------------------------------------+
                      |         InvisibleAct Gateway          |
                      |            POST /check                |
                      +---------------------------------------+
                                          |
                        +-----------------+-----------------+
                        |                 |                 |
                        v                 v                 v
                   [ ALLOW ]         [ REVIEW ]         [ BLOCK ]
                        |                 |                 |
                        v                 v                 v
                  Tool Executes      Action Halted    Action Aborted
                                    Pending Human     (0 Executions)
                                       Review

Pre-Execution Enforcement Invariant

Every action must be submitted to the authorization gateway (POST /check) prior to execution:

  • ALLOW: The action satisfies all policy, vendor, agent, trajectory, and spending constraints. The tool is permitted to execute.
  • REVIEW: The action involves sensitive data or exceeds financial/risk thresholds. Execution is halted. Tool execution is prevented until an authorized human operator grants explicit approval.
  • BLOCK: The action violates policy, uses an untrusted vendor, originates from an unapproved agent, or exhibits anomalous trajectory patterns. The action is aborted immediately. Zero tool executions occur.

3. Core Security & Governance Controls

3.1 Policy Enforcement & Trajectory Analysis

  • Action Policies: Tenant-specific policy rules define the baseline action decision (ALLOW, REVIEW, BLOCK).
  • Vendor Trust: Actions are verified against tenant-approved LLM providers and vendor trust registries. Calls from unapproved vendors are rejected with BLOCK.
  • Agent Registration: Agents must be explicitly registered and marked ACTIVE in the tenant agent registry. Unregistered or disabled agents are rejected with BLOCK.
  • Multi-Step Trajectory Detection: InvisibleAct analyzes prior session actions to detect exploit patterns (such as a destructive delete followed immediately by an invoice or funds transfer). Conflicting trajectories trigger BLOCK or REVIEW.
  • Cumulative Authority Limits: State-managed session tracking enforces spending ceilings (e.g., $10,000 session limit). Requests exceeding the remaining balance are blocked.
  • Single-Use Human Approvals: Approvals granted by human reviewers cannot be reused. Once consumed by an authorized call, the approval is permanently invalidated. Replay attacks are strictly blocked.

3.2 Tenant Isolation

  • Partitioned Persistence: All tenant data is logically isolated via database indexing and scoped tenant query filters.
  • Cryptographic Credential Binding: API keys and session tokens are strictly bound to a single tenant_id. Any attempt by Tenant A to query, review, or mutate Tenant B assets returns HTTP 403 Forbidden.
  • Isolated Metrics & State: Audit summaries, risk overviews, cumulative session spend, and approval IDs are completely partitioned. Tenant B cannot observe or consume Tenant A's state.

3.3 Role-Based Access Control (RBAC)

InvisibleAct enforces the principle of least privilege across five discrete roles:

Role Permitted Endpoints & Capabilities Restrictions
machine_agent POST /check runtime authorization Forbidden from dashboard, management, and audit endpoints (403).
auditor Read-only access to /audit, /risk, /policy, /agents, /vendors Prohibited from modifying policies, approving requests, or creating keys (403).
approval_reviewer View pending reviews and execute approvals/rejections (/approvals) Prohibited from modifying policies or issuing API keys (403).
tenant_admin Full management of tenant policies, agents, vendors, sessions, and keys Restricted strictly to their own tenant boundary.
master Cross-tenant administrative oversight, tenant provisioning, lifecycle status Dedicated administrative key/session required; not accessible by customer keys.

4. Cryptographic & Data Protection Controls

4.1 API Key & Secret Hashing

  • One-Way SHA-256 Hashing: Plaintext API keys and secrets are never stored in the database.
  • Generation-Only Exposure: The plaintext secret is displayed exactly once upon generation. Thereafter, only the cryptographic SHA-256 hash and a truncated audit key prefix (e.g., first 12 characters) are retained for logging and recognition.
  • Lifecycle Invalidation: API keys marked DISABLED, REVOKED, or EXPIRED are immediately rejected during authentication (HTTP 401 Unauthorized).

4.2 Session Security & Expiration

  • Opaque Session Tokens: Dashboard sessions use unpredictable, cryptographically secure 256-bit random tokens.
  • 12-Hour Absolute TTL: Sessions older than 12 hours from creation are automatically terminated.
  • 30-Minute Inactivity Timeout: Sessions idle for more than 30 minutes require re-authentication.
  • Server-Side Invalidation: Logging out via POST /auth/logout revokes the token server-side immediately.
  • Bulk Invalidation: Administrators can revoke all active sessions across an entire tenant via POST /auth/sessions/revoke-all.

4.3 Network & Database Encryption (TLS)

  • HTTPS/TLS: All public API endpoints communicate over TLS.
  • Database Connection Security: Where configured for PostgreSQL (e.g., Neon), database connections require TLS encryption (sslmode=require).
  • Fail-Closed Database Resilience: When configured for managed cloud PostgreSQL and connectivity fails, the system fails closed and refuses fallback to local unencrypted storage in production.

4.4 Production Log Sanitization

Container logs (stdout/stderr) are sanitized to eliminate sensitive information exposure:

  • Debug statements exposing tenant_id, session_id, previous_actions, or action parameters have been removed from runtime evaluation paths.
  • Audit records are stored in the secure backing database, not dumped into unencrypted standard output.

4.5 HTTP Security Headers & Information Masking

The gateway automatically injects protective headers into every HTTP response:

  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • X-XSS-Protection: 1; mode=block
  • Referrer-Policy: strict-origin-when-cross-origin
  • Server software fingerprinting headers (Server, X-Powered-By) are actively stripped.
  • Internal unhandled exceptions return structured JSON error envelopes with masked error IDs, preventing stack trace or internal path disclosure.
  • Interactive API documentation (/docs, /redoc, /openapi.json) is disabled in pilot, staging, and production environments.

5. Model Context Protocol (MCP) Integration Security

For AI agents integrating via Anthropic’s Model Context Protocol (MCP):

  • InvisibleAct MCP Adapter: Provides a pre-execution authorization wrapper around MCP tool execution.
  • Zero-Bypass Architecture: Tool executions are intercepted and submitted to /check before the local tool executes.
  • Mandatory Pre-Execution Check: If /check returns BLOCK or REVIEW, the tool function is never called. Zero tool executions occur without an explicit ALLOW.
  • Missing Context Rejection: If required identity parameters (tenant_id, agent, vendor, session_id) are missing, empty, or whitespace, the adapter fails closed and blocks execution.

6. Auditability & Data Lifecycle

  • Structured Audit Trails: Every authorization event is recorded with millisecond timestamps, actor attribution, risk scores, and decision rationales.
  • Configurable Audit Retention: Organizations can establish a customized audit retention period via tenant configuration. The administrative audit purge mechanism removes expired records without touching recent active history.
  • Administrative Tenant Deletion: An authenticated administrative tenant deletion capability permanently wipes all tenant-owned audit logs, session state, policies, vendor records, registered agents, API keys, and dashboard sessions.

7. Security Limitations & Boundaries

To maintain complete transparency and avoid misleading claims, InvisibleAct notes the following current architectural boundaries:

  1. Logical Rather than Physical Database Isolation: Multi-tenant deployments utilize a shared database schema with strict row-level logical query partitioning. Physical database-per-tenant isolation is not currently implemented.
  2. Standard Database Encryption at Rest: Data at rest relies on the underlying cloud database provider's storage volume encryption (e.g., AWS EBS / Neon volume encryption). Application-level field encryption is not currently implemented for non-credential fields.
  3. No Automated Background Retention Cron by Default: The retention cleanup API and database routines are implemented and verified; however, periodic execution must be scheduled via an external job runner (e.g., Kubernetes CronJob or cloud scheduled task).
  4. Administrative Deletion is Not Self-Service: Full tenant data deletion is an authenticated administrative operation executed by system administrators; an automated public self-service deletion portal is not currently exposed.
  5. Certification Status: InvisibleAct is built following enterprise security and privacy best practices, but does not currently hold formal SOC 2 Type II or ISO 27001 certifications.