Security/Version 1.0·Effective 19 July 2026

Information security overview.

This document sets out the technical and organisational measures maintained by Invoke in respect of the Service. It is published for the assistance of Customers and prospective Customers conducting vendor security assessments, and is intended to be forwarded in that capacity. Measures which are planned but not yet implemented are identified as such throughout.

security@invokehq.run →Section 12 — sub-processors

Document control

Version1.0

Effective date19 July 2026

Review cadenceQuarterly

Ownersecurity@invokehq.run

Section 1Summary of measures

Processing location	United States (us-east). Single region at present. Additional regions are available only by prior written agreement.
Data in transit	TLS 1.2 or higher on all external interfaces. HSTS is asserted on all `*.invokehq.run` hosts.
Data at rest	AES-256 at the storage layer, comprising managed database volumes, object storage and backups.
Authentication	Clerk for principals who are natural persons, supporting SSO and MFA. Prefixed API credentials for agent principals.
Credential storage	API credentials are retained as `SHA-256` digests. Plaintext is disclosed once, at the point of issue, and is not recoverable.
Tenant isolation	Organisation scope is bound at authentication and applied to all queries. Cross-tenant requests are answered with HTTP 404.
Audit record	Append-only, hash-chained ledger. Receipts are signed under HMAC-SHA256.
Use for model training	Prohibited. Customer Data is not used to train, fine-tune or evaluate any model, whether operated by Invoke or by a third party.
Sub-processors	Enumerated at Section 12 and maintained as a versioned record.
Point of contact	security@invokehq.run for disclosure, data processing agreements and security questionnaires.

1.1 Defined terms

Customer Data: Data submitted to, or generated by, the Service on behalf of a Customer, including execution metadata, receipts, workspace memory and organisation records.
the Service: The hosted Invoke control plane, comprising the API, the receipt store, the policy engine and Mission Control.
Foundry: The Invoke runtime as deployed by the Customer on infrastructure under the Customer's control.
Principal: Any authenticated actor, whether a natural person or an agent, to which an action is attributed.
Sub-processor: A third party engaged by Invoke which processes Customer Data in the course of providing the Service.

Sections 2 to 5Technical and organisational measures

Access control, cryptography, isolation and audit.

2.1Authentication: Access by natural persons is mediated by Clerk and supports email, OAuth and SSO authentication. Multi-factor authentication is available on all plans and may be enforced at organisation level by a Customer administrator. Agent principals authenticate by means of prefixed API credentials (inv_…) issued per agent, which are individually revocable and may be rotated without interruption of service. The control plane retains only a SHA-256 digest of each credential. Plaintext is disclosed once, at the point of issue, and cannot subsequently be recovered by Invoke or by the Customer.
2.2Authorization: Each request is resolved to an organisation, a workspace and a Principal prior to the execution of any handler. Administrative operations — credential management, policy amendment and approval — are segregated from execution by role. Agent principals are granted access solely to those tools exposed by the workspace to which they belong; an agent may not enumerate, invoke or otherwise discover a tool outside that workspace. Policy is evaluated on each invocation and is not cached at the point of connection.
3.1Cryptographic controls: All external traffic is terminated under TLS 1.2 or higher, with HSTS asserted on each host. Customer Data at rest, comprising the ledger, receipts and workspace records, is held in managed Postgres with AES-256 volume encryption; backups inherit the same protection. Integrity controls are maintained separately from confidentiality controls: each receipt is signed under HMAC-SHA256 and chained to its predecessor, such that alteration is detectable by a party in possession of the database.
4.1Tenant isolation: Organisation identity is bound at authentication and applied as a scope on every query path; no handler reads a workspace otherwise. A request in respect of a resource belonging to another tenant is answered with HTTP 404 and not HTTP 403, such that the API does not confirm the existence of another Customer’s resource. Agent registration, task claims, budgets and workspace memory are each keyed per workspace.
5.1Audit and logging: Each decision, tool invocation, policy determination, budget evaluation and approval is written to an append-only ledger as a hash-chained event. No function of the Service mutates historical records; corrections are recorded as subsequent events. The runtime console and the audit export constitute two views of the same chain. The endpoint GET /v1/runtime/workspaces/{ws}/ledger/verify re-walks the chain on demand for the purpose of demonstrating that no event has been altered or removed.

Section 6Data handling

Categories of data, retention and erasure.

6.1 Data processed

Execution metadata — tool identifier, arguments, Principal, timing, outcome and cost.
Receipts — the signed and chained record of each execution.
Workspace memory — context expressly shared between agents by the Customer, together with its revision history.
Identity and organisation records — accounts, roles, workspaces and credential digests.
Operational logs — request logs and error traces, retained on a short-term basis in accordance with Section 6.3.

6.2 Data not processed

Training corpora — no Customer Data is used to train, fine-tune or evaluate any model.
Plaintext credentials — digests only, in respect of both Invoke credentials and connector authentication.
Cardholder data — billing is administered by a payment processor; Invoke does not receive a primary account number.
Customer systems of record— the Service records that an invocation occurred and its result. It does not constitute a replica of the Customer’s database.

6.3Retention: Ledger events and receipts are retained for the lifetime of the workspace to which they relate, on the basis that an audit record subject to automatic expiry does not constitute an audit record. Operational logs are retained for a period of 30 days. Workspaces which have been deleted, together with their associated receipts, are purged within 30 days of deletion, including from backup media.
6.4Erasure and portability: A Customer may delete a workspace by way of the dashboard at any time. Account deletion in its entirety, and export of the ledger in a machine-readable format, are administered on request to security@invokehq.run and completed within 30 days. Export comprises the receipts together with their chain, such that evidentiary value is preserved on termination.
6.5Residency: All Customer Data is processed and stored within the United States at the date of this document. Residency within the European Union is an enterprise roadmap item. Customers for whom residency is a condition of procurement are asked to raise this prior to contracting.

Section 7Secrets management

Custody of credentials.

The governing principle of the Service is that the model does not hold the capability which it exercises.

7.1Custody: Connector credentials are held by the runtime — on local storage under .foundry/ in respect of local workspaces, or within the control-plane database in respect of hosted workspaces. Credentials are appended to the outbound request at the point of invocation and are not incorporated into a prompt, a completion or a tool argument at any stage.
7.2Protection: In transit, TLS 1.2 or higher. At rest, AES-256 volume encryption in respect of the managed database and its backups. The API does not return a stored credential under any circumstance; connector read operations expose has_auth: true and no further detail, such that a compromised dashboard session does not permit exfiltration.
7.3Envelope encryptionPlanned: Application-level envelope encryption under a managed KMS key, by which credentials would be rendered unreadable notwithstanding database access, is in development and is not implemented at the date of this document. No representation is made as to the date of implementation. Connector credentials presently rely upon storage-layer encryption as described at Section 7.2 together with the access restrictions at Section 7.4. Customers for whom this control is a condition of procurement are directed to Foundry, under which credentials remain on infrastructure under the Customer’s control.
7.4Access restriction: Production access is restricted to named engineering personnel, requires multi-factor authentication and is logged. No routine support procedure requires the reading of Customer credentials. Access entitlements are reviewed upon any change of role and upon termination of engagement.

Section 8System architecture

Trust boundaries.

The Service comprises two planes. Foundry operates on infrastructure under the Customer’s control; the control plane maintains the shared and tamper-evident record. A full technical description is published at architecture.

8.1

Foundry

Runtime under Customer control — policy, identity and ledger held locallyCustomer

8.2

Invoke Cloud

TLS ingress; authenticated and scoped to organisationInvoke

8.3

Control Plane

Policy engine, budget evaluation and approvalsInvoke

8.4

Receipt Store

Append-only, hash-chained and signedInvoke

8.5

Mission Control

Read model derived from the ledgerInvoke

8.6 Failure mode

The execution pipeline fails closed. Where policy cannot be evaluated — by reason of the control plane being unreachable, budget being indeterminate, or an approval remaining unresolved — the effect is not executed. Invoke does not provide for ungoverned execution as a degradation path under any configuration.

Section 9Compliance

Certifications and programmes.

The following statements are made as at 19 July 2026. Invoke does not assert the holding of any certification which it does not hold.

Programme	Status	Statement
SOC 2 Type II	Planned	Controls are being formalised in advance of an audit window. Invoke does not hold a report at the date of this document and no representation is made as to the date of issue. Current status is available on request.
GDPR	Supported	Customer Data is processed on documented instructions. Rights of deletion and portability are administered in accordance with Section 6.4. Residency within the European Union is not presently available.
Data Processing Agreement	Available	A data processing agreement addressing processing, sub-processors and breach notification is available on request at security@invokehq.run.
Independent penetration test	Planned	A first third-party assessment is scheduled to coincide with the audit window referred to above. Any summary letter will be made available subject to a non-disclosure agreement.
HIPAA · FedRAMP	Not offered	The Service is not suitable for protected health information or for federal workloads. Invoke makes no claim of eligibility in respect of either programme.

Sections 10 and 11Vulnerability disclosure

Disclosure policy and incident response.

10.1 Point of contactsecurity@invokehq.run

Reports are acknowledged within one business day and receive a substantive response within five business days.

10.2 Encrypted transportPGP key — planned

Not published at the date of this document. Researchers requiring encrypted transport in the interim should request a channel by the address at 10.1.

10.3 Safe harbourGood-faith research

Invoke does not initiate legal proceedings in respect of research conducted in accordance with Section 10.4.

10.4Researcher obligations: Researchers are asked to afford Invoke a reasonable period in which to remediate an issue prior to publication; a period of 90 days is applied by default, and remediation is ordinarily completed considerably sooner. Testing is to be conducted only against accounts owned by the researcher or in respect of which permission has been granted. Researchers must not access, modify or exfiltrate the data of another Customer, and are asked to demonstrate an issue without recourse to production data where it is possible to do so. Denial-of-service testing, unsolicited messaging, social engineering and physical attacks against personnel or providers are excluded from safe harbour. Invoke does not presently operate a paid bounty programme. Public credit is given at the election of the researcher.
11.1Incident response: Reports and alerts are triaged by an on-call engineer against a documented severity scale. A confirmed incident is assigned a single owner, a contemporaneous timeline is maintained, and containment is effected in priority to root-cause analysis.
11.2Notification: Where an incident affects Customer Data, Invoke notifies the affected Customer without undue delay and in any event within 72 hours of confirmation. Notification comprises the nature of the incident, the categories of data involved, the measures taken by Invoke and the measures recommended to the Customer. A written post-incident review is issued in respect of any incident affecting Customers.

Section 12Sub-processors

Register of sub-processors.

This register is authoritative as at 19 July 2026. Customers party to a data processing agreement are notified in advance of any addition, in accordance with the terms of that agreement.

Provider	Purpose of processing	Location
Vercel	Frontend hosting and edge delivery	United States
Render	API and control-plane compute	United States
Supabase	Managed Postgres — ledger, receipts, workspace records	United States (AWS)
Amazon Web Services	Underlying infrastructure for managed Postgres and backups	United States
Clerk	Authentication, session and organisation management	United States
PostHog	Product analytics in respect of the web application (first-party proxied)	United States
Model providers	Engaged only where the Customer elects to route model traffic through the Service; prompts are transmitted to the provider selected by the Customer	Per provider

Section 13Availability and resilience

Regions, backups and recovery.

13.1Status reportingPlanned: A public status page recording incident history is in development and is not available at the date of this document. Pending its publication, incidents are communicated by electronic mail to affected workspaces.
13.2Regions: A single region within the United States in respect of both compute and database. Multi-region failover and residency within the European Union are enterprise roadmap items.
13.3Backups: Managed Postgres with automated daily backups and point-in-time recovery across a seven-day window. Backups are encrypted at rest and restoration procedures are exercised rather than assumed.
13.4Recovery objectives: The following are stated as internal targets and do not constitute contractual commitments save where incorporated into an enterprise agreement: recovery point objective of 24 hours from automated backup, and materially lower within the point-in-time recovery window; recovery time objective of 4 hours in respect of control-plane restoration. Foundry continues to govern locally throughout, such that local execution is not contingent upon restoration of the Service.

Section 14Frequently raised questions

Questions arising in vendor assessment.

Are secrets disclosed to the model?

No. Credentials are held by the runtime and appended to the outbound request at the point of invocation, subsequent to the model having determined the tool to be called. The model is exposed to the tool schema and to the result, and is not exposed to key material at any point. Receipts record secret_exposed_to_agent: false, such that the position is demonstrable per execution rather than asserted as policy.

Is Customer Data used to train models?

No. Customer Data is not used for training, evaluation or fine-tuning, and is not disclosed to model providers for those purposes. Where the Customer elects to route model traffic through the Service, prompts are transmitted to the provider selected by the Customer and are governed by that provider’s terms. Customers are advised to confirm the applicable training settings with that provider directly.

Is self-hosting available?

In part. Foundry operates in its entirety on infrastructure under the Customer’s control, with the ledger held on local storage and no network dependency in respect of governed execution. A fully self-hosted control plane — comprising the hosted ledger, approvals and Mission Control — is an enterprise roadmap item and is not a generally available product at the date of this document. Customers for whom self-hosting is a condition of procurement are asked to raise this prior to implementation against the hosted API.

Where are receipts held?

In the plane in which they were generated. Foundry writes receipts to a local hash-chained ledger. On execution of foundry push, receipts are written to managed Postgres within the United States region and become visible to the Customer’s organisation in Mission Control. Both are verifiable by the same command and under the same chain rules; the location of storage does not qualify the guarantee.

May Claude Code and Codex be connected?

Yes. A workspace is exposed as an MCP server, and any MCP-capable client may attach to it, including Claude Code, Claude Desktop, Cursor and Codex, together with the OpenAI and LangChain SDKs by way of the same endpoint. Such clients are presented with ordinary tools. Each invocation is attributed to a Principal, evaluated against policy, assessed against budget and recorded to the ledger in transit.

What is the behaviour of the Service in the event of an outage?

Foundry continues to govern locally; local ledger operations and policy evaluation carry no dependency on the control plane, and receipts are queued for subsequent transmission. In respect of hosted workspaces the failure mode is closed: where policy cannot be evaluated, the effect is not executed. Invoke does not permit ungoverned execution as a degradation path.

How are changes to sub-processors notified?

The record at Section 12 is authoritative and dated. Customers party to a data processing agreement are notified in advance of a new Sub-processor commencing processing of Customer Data, and may object within the period specified in that agreement. Requests to be added to the notification list should be directed to security@invokehq.run.

Vendor assessment

Further enquiries.

Security questionnaires are completed by the engineering team responsible for the controls described in this document. Where a control is not implemented, that position is stated.

Contact security →Statement of guarantees