I/O Mesh — Security

1. Where the software runs#

I/O Mesh is a self-hosted Go binary that you install and operate on infrastructure you control. It is a local decision service that your systems ask before using a model or tool. It answers allow or deny and writes an audit record either way, and your systems make the call. It does not sit in the path of the tool call and does not fetch model or tool endpoints. The decision service does not receive prompts or model outputs; it evaluates request metadata (such as caller, department, tool, and related fields) under your policy. Audit records, signed audit heartbeats, single-use signed pin receipts and approve receipts you hold, and other data on your systems stay with you. We do not host them and cannot access them unless you send them to us.

2. You choose the model#

I/O Mesh does not include an AI model and never fetches model weights. You decide which model to connect and where it runs. Your agreement with the model provider governs data you send to that model. The Self-hosted Software includes an operator command that sends a weights report to a server address you set, intended for your own running decision service. It runs only when you run it. The report contains a weights hash that you supply, a signature you make with your runtime key, and related report details. The command has no built-in destination, and no I/O Mesh address is built into it: it sends the report only to the address you set. It does not read, fetch, or send model weights.

3. Outbound connections#

The Self-hosted Software has no built-in destination; every destination is set by the operator. It makes an outbound request only in the five cases below. Each destination comes from your configuration or a command-line flag.

• Operator command. An operator command POSTs a signed weights hash to a URL the operator gives, normally their own running decision service. Destination: the URL the operator gives. Trigger: an operator runs it by hand; nothing runs it automatically. Default: never runs on its own.
• OIDC discovery and the JWKS fetch. Destination: the operator-configured issuer in IOMESH_OIDC_ISSUER, and the key address its discovery document names. Trigger: at startup and on each key refresh. Default: on by default, unless a local JWKS file is set in IOMESH_OIDC_JWKS_FILE; then the issuer is not contacted.
• Heartbeat feed URL. Destination: the HTTPS address you set in IOMESH_FEED_URL. Trigger: after each signed audit heartbeat is written, and after each audit record when IOMESH_FEED_AUDIT is true. Default: off by default.
• L2 advisor and escalate page. Destination: the addresses you set in IOMESH_L2_ENDPOINT and IOMESH_L2_PAGE_URL. Trigger: a grey request in an enabled autonomy tier asks the advisor; if the advisor escalates, a page is sent and the request is still denied. Default: off by default.
• Class-denial notify webhook. Destination: the HTTPS address you set in IOMESH_NOTIFY_URL. Trigger: after a denial for a tagged tool class and its audit record are stored; an allow never sends it. Default: off by default.

4. Decisions#

A call to a tool in the human-approval class is refused unless it presents a valid single-use Ed25519 approve receipt. The receipt is signed out of band by a person registered as an approver for that department, who is not the caller. It is bound to the department, tool, tool class, and caller, and is valid only within the time window it states. A receipt is accepted only on an L1 request. A request that asks for L2 is refused even with a valid receipt. A valid receipt does not by itself allow the call. The call must still pass the remaining checks and your card and department policy, and any of them can deny it. A receipt can allow at most one call. A receipt that has already been spent is refused. An allow made with a receipt is written to the audit log with that receipt's identifier. The receipt does not bind call arguments or amounts. The approver's private key stays where the approver signs; the running server does not load it. A single-use signed pin receipt is required before a card version goes into service in a named department. The pin receipt names the department, card, and card version, has a limited validity period, and can be used only once. The software refuses a pin receipt that is expired, signed by a different key, issued for a different card, version, or department, or already used. An allow returns an endpoint string and a process id. The software does not fetch that endpoint, inject tool credentials, or stop a process that is already running. Revoke means the next resolve is rejected. A caller that already holds an endpoint is outside that decision. Each decision is written to the audit log. A request is not a grant.

5. Audit heartbeats#

The decision service writes an audit record for each decision it makes. At regular intervals, when the audit heartbeat log is enabled, it also produces a signed audit heartbeat: a summary that covers the audit records written since the previous heartbeat, including a fingerprint (hash) of those records, counts of what was allowed and refused, a sequence number, and a fingerprint of the previous heartbeat. Each heartbeat is signed with an auditor key that you hold. Because each heartbeat refers to the one before it, and its fingerprint must match the underlying records, the heartbeats are designed to help you detect a missing heartbeat or an altered audit record. Audit records written since the most recent heartbeat are not yet covered, and the heartbeats do not detect changes made by someone who holds your auditor key. Individual audit records are not chained to one another. The signed audit heartbeats (together, the "audit heartbeat chain") are a product feature to help you review activity; they are not a certification, an attestation, or proof of compliance with any law or standard.

6. Department pins#

You pin specialist cards to a department. A request is evaluated only against a card that is pinned for the caller's department (subject to exact caller-and-tool denials configured before policy). The documentation describes how pins and denials are configured.

7. Your responsibilities#

Because the decision service runs on your infrastructure, you are responsible for host security, network controls, key management (including approver signing keys), backups, availability, monitoring, patching, and the models you connect. Install updates promptly.

8. Data we do handle#

We operate our website, account, licensing, billing, and email support on iome.sh. The Self-hosted Software does not phone home and does not send us Customer Content. If you send logs, pin receipts, or approve receipts for support, send only what is needed, and do not send private signing keys or receipts that are still within their validity window. See our Privacy Policy.

9. Compliance status#

• I/O Mesh is not a compliance certification, and using it does not make you compliant with any law or standard.
• We do not claim a SOC 2 Type II report.
• We do not claim HIPAA certification. We will not process protected health information unless a Business Associate Agreement has been signed.
• We do not claim ISO certification.
• Any security questionnaire responses or controls summaries we provide are informational and do not amend your agreement.

10. Support#

Email support at support@iome.sh, 9am to 5pm PT on business days (Monday to Friday, excluding British Columbia statutory holidays). We aim to reply within one business day. We do not offer 24/7 support or a service-level agreement.

11. Reporting a vulnerability#

Report suspected vulnerabilities to security@iome.sh. Please give us reasonable time to investigate before public disclosure, and do not access or modify data that is not yours.