Home / Trust & Legal / Privacy Policy

Privacy Policy

How InvisibleAct processes, stores, retains, and protects authorization metadata under a strict data-minimization architecture.

Version: 1.0.0
|
Effective Date: September 2026
|
Status: Active
|
Scope: InvisibleAct.com Platform & APIs

1. Scope

This Privacy Policy applies to the InvisibleAct runtime authorization platform, APIs, administrative endpoints, customer dashboard, and official marketing website (invisibleact.com).

InvisibleAct provides pre-execution authorization, policy enforcement, and runtime governance for autonomous AI agents. This policy describes how we collect, process, store, retain, and protect data in connection with the currently implemented InvisibleAct software and services.

2. Information InvisibleAct Processes

InvisibleAct operates under an intentional, metadata-only architectural model. InvisibleAct processes only the structured operational metadata strictly necessary to render real-time authorization decisions, maintain audit trails, and manage tenant configurations.

2.1 Authorization Metadata

When an AI agent or application queries the InvisibleAct runtime gatekeeper (POST /check), the following structured fields are processed:

  • Tenant Identifier (tenant_id): Scopes the authorization check to the customer's organization.
  • Agent Identity (agent): The registered identifier or name of the initiating AI agent.
  • Vendor Identity (vendor): The underlying LLM or model provider (e.g., openai, anthropic).
  • Action Identifier (action): The operation requested by the agent (e.g., READ_INVOICE, TRANSFER_MONEY, EXPORT_CUSTOMERS).
  • Amount (amount): Numerical financial or operational transaction values, if applicable.
  • Session Identifier (session_id): Customer-provided session or execution thread identifier.
  • Tool Identifier (tool): The registered tool being invoked (e.g., invoice_tool).
  • Data Access Classification (data_access): Classification tier of data targeted by the action (e.g., PUBLIC_DATA, INVOICE_DATA, PAYMENT_DATA).
  • Delegation Context: authorized_by and delegated_by metadata fields indicating authorization lineage.
  • Approval Reference (approval_request_id): Unique identifier referenced when executing an action previously approved by a human reviewer.

2.2 Audit Logs

InvisibleAct records immutable event records for every authorization evaluation:

  • Unique request ID (request_id UUID)
  • Tenant identifier (tenant_id)
  • Action, tool, amount, agent, and vendor identifiers
  • Cumulative session spend and trust score metrics
  • Risk classification (LOW, MEDIUM, HIGH)
  • Authoritative decision (ALLOW, REVIEW, BLOCK) and decision rationale
  • ISO-8601 timestamp
  • Human approval state (review_action, authenticated reviewer identity, review timestamp, permanent single-use consumption invalidation)

2.3 Tenant Configuration

To govern authorization policies, InvisibleAct stores tenant-specific configuration in dedicated data structures:

  • Action Policies: Mapping of actions to policy decisions (ALLOW, REVIEW, BLOCK).
  • Vendor Trust Registries: List of approved LLM providers and model vendors per tenant.
  • Tenant Agent Registry: Registered agent identities, associated vendors, and active/disabled statuses.
  • Canonical Tenant Workspace Profiles: Organization name, company name, contact email, lifecycle status (ACTIVE, SUSPENDED, REVOKED), and creation metadata.

2.4 Authentication & Security Metadata

To secure access to APIs and dashboards:

  • Provisioned API Credentials: Key prefix identifier (e.g., first 12 characters for recognition), role assignment (machine_agent, tenant_admin, approval_reviewer, auditor), lifecycle status (ACTIVE, DISABLED, REVOKED, EXPIRED), creation and expiration timestamps. Plaintext secret keys are never stored; only one-way cryptographic SHA-256 hashes are persisted.
  • Dashboard Sessions: Server-side session tokens, SHA-256 token hashes, assigned role, absolute expiration timestamp (12-hour TTL), and sliding inactivity timestamp (30-minute timeout).

2.5 Website / Demo Lead Information

For visitors who submit demo or pilot requests via our website form (POST /leads):

  • Contact name, business email address, company name
  • Target AI framework (e.g., LangChain, CrewAI, AutoGen)
  • Submission timestamp and referral source

3. Information InvisibleAct Does NOT Process

Key Architectural Invariant: InvisibleAct is strictly an authorization and policy gatekeeper. InvisibleAct does not collect, inspect, ingest, or store customer content payloads.

Specifically, InvisibleAct does NOT process or store:

  • Customer prompt text or natural language inputs
  • AI model outputs, responses, reasoning traces, or completions
  • AI model training weights or parameters
  • Customer document contents, attachments, or unstructured files
  • Customer database records, schemas, or customer end-user personal data
  • Raw API payloads passing between AI agents and external tools

Tools and agents execute directly within the customer's own runtime environment. InvisibleAct evaluates only pre-execution authorization parameters before allowing or halting tool execution.

4. Data Storage

  • Local / Self-Hosted Development & Testing: Data is stored in embedded SQLite database files located within the customer's deployment boundary.
  • Managed / Cloud Production Deployments: Where configured, data is stored in PostgreSQL database instances (such as Neon) over TLS-encrypted connections (sslmode=require).
  • Storage Location: Backing databases are deployed within infrastructure managed by InvisibleAct or in the customer's cloud environment, depending on the commercial deployment model.

5. Data Retention

Data retention schedules are established by data category:

  • Audit Records: Retained indefinitely by default to ensure regulatory auditability. Organizations can establish a customized audit retention period via tenant configuration, where records older than the configured threshold become eligible for purge via automated retention routines.
  • Dashboard Sessions: Governed by automated expiry rules:
    • 12-Hour Absolute TTL: Sessions older than 12 hours from creation are automatically rejected and expired.
    • 30-Minute Inactivity Timeout: Sessions with no activity for 30 minutes are automatically rejected.
    • Immediate Logout Invalidation: Explicit logout immediately marks the server session as REVOKED.
  • API Credentials: Retained until explicitly rotated, disabled, or revoked by administrators.
  • Tenant Configuration: Retained actively throughout the customer agreement lifecycle.
  • Website Lead Data (leads): Retained for prospective customer communications and pilot provisioning.

6. Data Deletion

6.1 Configurable Retention Cleanup

For audit log maintenance, InvisibleAct provides an administrative audit purge mechanism:

  • Purges only records older than the configured retention cutoff date.
  • Leaves recent records within the retention window completely untouched.
  • Enforces strict tenant boundaries during tenant-scoped cleanups.

6.2 Administrative Tenant Deletion Capability

InvisibleAct includes an administrative tenant deletion capability to permanently delete all data belonging to a specified tenant.

When executed, the system permanently purges records matching the tenant across:

  • Audit logs and decision history
  • Active session state and cumulative session spend tracking
  • Tenant-specific policy rules
  • Vendor trust registries
  • Tenant agent registry
  • Provisioned API credentials and access keys
  • Active and historical dashboard session tokens
  • Canonical tenant workspace profiles (where specified)
Administrative Operation: This is currently implemented as an authenticated administrative operation requiring Master Administrator credentials and explicit confirmation strings (DELETE <tenant_id>). It is not currently exposed as a public self-service deletion portal.

7. Tenant Isolation

InvisibleAct enforces logical tenant isolation across all layers:

  • Database Partitioning: All tenant-owned records require an explicit tenant_id foreign key. Database queries filter strictly on tenant boundaries using strict database indexing and scoped tenant query filters.
  • Credential Scoping: API keys and dashboard session tokens are cryptographically associated with a single tenant. Attempts to query or mutate another tenant's policies, audits, agents, or keys return HTTP 403 Forbidden.
  • Cross-Tenant Spend & Approval Protection: Cumulative spend tracking, approval request IDs, and trajectory evaluations are strictly isolated; one tenant cannot view or consume another tenant's approvals or spend limits.
  • Deletion Boundaries: Deletion operations on Tenant A cannot affect, alter, or delete records belonging to Tenant B.

8. Security Measures

The following technical and organizational controls are currently implemented:

  • Pre-Execution Gatekeeping: AI agent tools execute only if an explicit ALLOW decision is returned prior to execution.
  • One-Way Credential Hashing: API key secrets and session tokens are hashed using cryptographic SHA-256 before storage. Plaintext secrets are never stored in databases.
  • Transport Layer Security (TLS): All public endpoints operate over TLS/HTTPS. PostgreSQL database adapters enforce TLS (sslmode=require).
  • Production Log Sanitization: Runtime container logs do not emit sensitive tenant identifiers, session tokens, customer action parameters, or trajectory histories.
  • HTTP Security Headers: Endpoints inject X-Content-Type-Options: nosniff, X-Frame-Options: DENY, X-XSS-Protection: 1; mode=block, and Referrer-Policy: strict-origin-when-cross-origin. Server software disclosures (server, x-powered-by) are stripped.
  • Error Sanitization: Production runtime errors return generic HTTP 500 error envelopes with masked error IDs, preventing internal path, database, or stack trace disclosures.
  • Rate Limiting: Public endpoints (/leads, /auth/session) enforce sliding-window rate limiting to prevent brute-force attacks and abuse.
  • Role-Based Access Control (RBAC): Granular roles (machine_agent, tenant_admin, approval_reviewer, auditor, master) enforce principle of least privilege.

9. Third-Party Services & Subprocessors

InvisibleAct utilizes a minimal set of third-party infrastructure and service providers:

  • Hosting / Compute: Render (cloud application platform hosting the gateway API).
  • Database Persistence: Neon / PostgreSQL (managed serverless PostgreSQL, where configured).
  • Edge Routing / DNS: Cloudflare (DNS resolution and reverse proxy, where configured).
  • Transactional Email: Resend (api.resend.com), used exclusively to dispatch lead notification emails when website demo forms are submitted, where RESEND_API_KEY is configured.

For complete details on third-party service providers, please review our Third-Party Subprocessors Documentation.

10. Data Transfers

Where InvisibleAct cloud services are utilized, data may be hosted on infrastructure located in the United States or other regional cloud provider zones. Because InvisibleAct processes only metadata and business contact data—and does not process customer content payloads—cross-border transfers are limited to authorization metadata and operational logs.

11. Customer Responsibilities

Customers using InvisibleAct are responsible for:

  • Safeguarding generated API keys and administrative credentials.
  • Selecting appropriate policy rules and human review thresholds for their AI agents.
  • Ensuring their AI agents supply accurate metadata identifiers (tenant_id, agent, vendor, action).
  • Managing their own internal data retention policies and triggering retention cleanup or deletion requests as required by their governance requirements.

12. Privacy Requests & Inquiries

To request data deletion, inquire about stored metadata, or exercise privacy-related rights, authorized customer representatives may contact our privacy team:

Requests for tenant data deletion are verified against administrative authorization records and processed via our administrative deletion capability.

13. Changes to This Policy

We may update this Privacy Policy from time to time to reflect system updates, security enhancements, or legal requirements. Updated versions will be published with an updated Effective Date. Continued use of InvisibleAct services following notification or publication constitutes acceptance of the revised policy.