inhold Book a call

For AI agent vendors whose hospital deals are stuck in security review

Your agent's memory store stays in your customer's cloud.Their reviewer can check every read.

Your deal is waiting because nobody can say where your agent's memory lives or who read it. Inhold is the context layer your agent reads and writes through, built to install in your customer's own cloud account. It checks policy on every read and logs each decision, allowed or denied, in a hash-chained audit trail. You hand the reviewer an evidence pack they can check. The AWS install is written and tested in CI, not yet run in a real AWS account.

Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.

Where Inhold runs Target AWS design: Inhold, records and the audit chain sit in the customer's account. The agent shown inside may instead run in the vendor's account and receives what policy lets it read. Inhold has no route to Inhold the company. Its only outbound calls go to AWS in the customer's account: STS for agent sign-in, S3 and KMS for audit anchors. Today v0 runs on one machine. YOUR CUSTOMER'S CLOUD ACCOUNT Your agentMCP or REST inhold policy check on every call one audit row per decision Their recordstheir KMS key Audit chainhash-linked no route out to Inhold the company Inholdthe company NO ACCESS Reviewerevidence pack
Where Inhold runs Target AWS design: Inhold, records and the audit chain run in the customer's account. The vendor's agent receives what policy lets it read and may run outside that account. Its only outbound calls go to AWS in the customer's account: STS for agent sign-in, S3 and KMS for audit anchors. Today v0 runs on one machine. YOUR CUSTOMER'S CLOUD ACCOUNT Your agentMCP or REST inhold policy check on every callone audit row per decision Their recordstheir KMS key Audit chainhash-linked no route out to Inhold the company Inholdthe company NO ACCESS Reviewerevidence pack

Why deals stall

The reviewer asks three questions about your agent's data. A policy PDF does not show what the agent read. An audit log does.

Health system, bank and law firm security teams ask the same things in different words. Here is what the local v0 export contains and what depends on the AWS install.

The reviewer asksWhat you hand overFile in the evidence pack
Where does the agent's memory live?With the AWS install, in their own cloud account on their key. Today on one machine. The data flow diagram shows the target design. In v0 everything sits in one unencrypted SQLite file on one machine.DATA_FLOW.md
Who can read it?Only the agents and people named in their policy bundle, only for the purposes registered to each. The bundle is a JSON document their team owns and can diff. After the first boot, changes take effect only through the policy API, which logs them.policy/active_bundle.json
How would we know?One audit row for every decision, allowed or denied, each carrying the hash of the row before it and the hash of the policy in force. The pack includes a verification result. In the demo pack it reads ok: true, with anchors signed by a synthetic demo key.audit/chain_verification.json

What a reviewer sees

Every read is a row. Denied ones too.

The billing agent asked for a note labelled PHI. Its purpose does not allow PHI, so the read was refused and logged. The correction from nurse.rivera produced a draft skill that himadmin.chen approved.

Illustrative rows written for this page, shaped like the audit log, not exported from the demo. Every name is invented.

audit_event, samplesynthetic hospital, not real data
seqtimeactoractionobjectlabelspurposedecisionengine_hashsession_idprev_hashrow_hash
041714:09:40prior-auth-agentreadskl_77d1a2b3c4d5internalprior_authallowf3e8adf97bd08374e6377156093cad64
041614:09:31himadmin.chenskill_approveskl_77d1a2b3c4d5internalprior_authallowf3e8adf97d130ee276acdc5de6377156
041514:05:40nurse.riverawriteskl_77d1a2b3c4d5internalprior_authallowf3e8adf989eb9987f597174876acdc5d
041414:05:40nurse.riverawritectx_19a0b2c3d4e5PHIprior_authallowf3e8adf989eb99878fdf0ea2f5971748
041314:05:40nurse.riverareadctx_8f2c0a1b3d4ePHIprior_authallowf3e8adf989eb998702e2ce068fdf0ea2
041214:02:12billing-agentreadctx_8f2c0a1b3d4ePHIbillingdenyf3e8adf96da06d724ebbb6d002e2ce06
Prior head at seq 0411, illustrative: 4ebbb6d0. Policy hash, synthetic samplesha256:03178aa8406bc75210aa3b6796f24949d770a057a7ef3490d83d314dcb3939c7

What Inhold does

Built for the security review, then for your agent

Checks every call against their policy

Every call runs under a purpose: named in the REST request, or fixed for the session on MCP. Inhold checks the caller, the purpose and the data labels against the customer's bundle. Deny is the default, admins included.

Logs every decision in a chain

Each policy decision writes one row, allowed or denied, so a search can write several. Rows are append-only and hash-linked, so editing one breaks verification. Each row names the policy version that decided it.

Labels sensitive data at write time, locally

Detectors for health identifiers (MRN, date of birth, ICD-10, NPI, member id) and personal ones (SSN, email, phone) run locally, with no network call. A caller can add a label, such as one for client or account data, and can never remove one.

Turns corrections into skills an approver signs off

When a nurse, loan officer or paralegal corrects the agent, the correction is stored with a diff and becomes a draft skill. No agent uses it until a named approver signs off. Approval needs the skill approver role, which the default bundles give only to people.

Exports an evidence pack

A zip with the policy, the audit rows, the chain check, a control map to eight lines of 164.312 and the minimum necessary standard, and answers to 20 common reviewer questions. The map does not yet cover emergency access, automatic logoff or the (e)(2) specifications. A manifest lists the SHA-256 of every file.

Integration

The same Memory methods, now async, through Inhold

Connect your agent to the MCP server. The server binds identity and purpose at session start; the model cannot change them in a tool call.

Trimmed from the integration demo. Follow the request through Inhold.

# before: local memory, trimmed
class Memory:
    def __init__(self): self._items = []
    def add(self, text): self._items.append(text)

# after: MCP client, trimmed
# Identity and purpose bind when the MCP server starts.
class Memory:
    def __init__(self, session): self.session = session

    async def add(self, text):
        await self.session.call_tool("context_write",
            {"kind": "memory", "body": text})

    async def search(self, query):
        r = await self.session.call_tool("context_search",
            {"query": query})
        # Response handling omitted here; see the full demo.

Evidence pack

Files your reviewer can inspect

The export includes the policy, audit evidence and control answers. A manifest lists each file's SHA-256.

File names match the real evidence pack. The fragments below hash illustrative sample contents at build time. They do not verify a customer export or an install. The egress statement describes the AWS design; the security group it mentions ships with the install.

Read the sample contents and recompute the hashes.

inhold-evidence-pack.zipSHA-256, sample
  • CONTROL_MAP.mde183b265e658Sample hash: verified
  • DATA_FLOW.md403bfdd5e78bSample hash: verified
  • HASHING.md7516b2bcc98aSample hash: verified
  • MANIFEST.jsonca5e8500bbb8Sample hash: verified
  • THREAT_MODEL.mda43ad4ddd734Sample hash: verified
  • TOP20_ANSWERS.md9340294271afSample hash: verified
  • anchors/
    • anchors.jsonle14147a027f0Sample hash: verified
  • audit/
    • audit_events.jsonl9542eac0e552Sample hash: verified
    • chain_verification.jsona131e9fa688cSample hash: verified
    • summary.json637cb81dcc9fSample hash: verified
  • deployment/
    • egress_statement.mdb3d7867a8a5eSample hash: verified
  • policy/
    • active_bundle.json51c616cb4dc2Sample hash: verified
    • active_bundle.sha256574a60a0a394Sample hash: verified
    • inhold.rego793e72a1c31dSample hash: verified

Who it is for

Starting with prior authorization agents for US health providers

Any agent vendor whose customer runs a security review hits the same three questions. We are starting with one kind of buyer, so we can go deep on its review.

Now: prior authorization agents

Vendors selling prior authorization agents to US hospitals and medical groups. Their reviewers check access control and audit under HIPAA 164.312, and some questionnaires now ask about vector stores and agent memory by name. Inhold maps its controls to 164.312, and the demo is a synthetic hospital running a prior authorization agent. See the hospital review questions.

Later: banks, lenders and law firms

Their reviews ask the same questions under different rules: the Interagency Guidelines and third-party risk guidance for banks, NCUA for credit unions, the FTC Safeguards Rule for non-bank lenders, and ABA Formal Opinion 512 for law firms. We have not written control maps for these, and matter walls and legal hold for law firms are not built.

What Inhold does not do

What Inhold leaves out

No model calls

Inhold makes no model calls over the network. Which model your agent calls, and under what agreement, is between you and your customer; Inhold does not control it.

No access to customer data

Inhold the company has no account or route into the planned customer install. Your customer's policy controls each caller's access.

No compliance certificate

The control map is evidence for a reviewer. The covered entity owns its configuration and policies.

No customers yet

v0 runs on one machine with synthetic data. The AWS install is in build.

Where we are

Early, and saying so

Inhold v0 runs on one machine with a synthetic hospital: policy checks, the audit chain, PHI labels, corrections, the MCP server and the evidence pack all work and are tested in CI, including 30 red-team cases. The build log lists what has shipped and what is next.

The install into a customer's AWS account is being built now. IAM-role sign-in for agents and MCP over HTTP on the gateway are in v0. Sign-in tests use generated OIDC keys and a stand-in for STS; neither has been tried against a real identity provider or AWS account. The mTLS fallback is not built. The security gap list records what is not built.

The code goes public on 9 Nov 2026 under the Apache-2.0 licence. We are looking for three prior authorization agent vendors with a hospital deal stuck in review.

Questions

Short answers

What is Inhold?

Inhold is a context layer for AI agents, designed to run inside your customer's own cloud account; today v0 runs on one machine. Your agent reads and writes memory through it, every call is checked against the customer's policy, and every decision is written to an audit log their reviewer can verify.

Who is Inhold for?

Inhold is for AI agent vendors whose deals are stuck in security review because the reviewer will not accept the agent keeping memory in the vendor's cloud. We are starting with vendors of prior authorization agents selling to US health providers; banks, lenders and law firms come later.

How is this different from AWS AgentCore Memory?

AgentCore Memory isolates memory by user and tenant, with Cedar policies enforced at AgentCore Gateway, and uses models to extract long-term memories. Inhold decides each read and write by purpose and by the label on each item, such as PHI or PII, makes no model calls on your data, and writes one hash-chained audit row per decision, which goes into an evidence pack for the security reviewer. Inhold has no AgentCore adapter today. Bring your own cloud: Inhold installs in your own AWS account, with Azure and GCP when a customer needs them. The AWS install is written and tested in CI but not yet run in a real AWS account.

Where does my agent's memory live with Inhold?

With Inhold's planned AWS install, the agent's memory lives in a database in your customer's cloud account, on a key they own, with no account or network route for Inhold the company. Today v0 runs on one machine with SQLite.

Is Inhold HIPAA compliant?

No software is HIPAA compliant on its own, and Inhold does not claim to be. Inhold maps what it does to 45 CFR 164.312 line by line. Compliance depends on the covered entity's own configuration and policies.

Does Inhold send any data back to you?

No. Inhold has no telemetry, licence server or update check. On a laptop the running service makes no outbound calls. In AWS mode, built in code and not yet run on real AWS, it calls only AWS services in your account, through your VPC endpoints: STS once per agent sign-in, and S3 and KMS (kms:GenerateMac, kms:VerifyMac) to write and check its audit anchors. The install's endpoints for ECR, CloudWatch Logs and Secrets Manager serve the container platform. No call ever goes to Inhold the company. The install checker, inhold doctor, reads AWS APIs when you run it. A test in CI runs the demo with outbound connections blocked.

Does Inhold call an AI model with my customer's data?

No. Inhold makes no model calls over the network. The only model inside it is the optional local name detector, which runs from files on disk. Which model your agent calls is between you and your customer.

How does my agent connect to Inhold?

Your agent connects to Inhold over MCP (stdio or HTTP) or REST. Each call runs under a purpose, such as prior_auth or billing: named in the REST request, or fixed for the session on MCP. The agent's identity is fixed at sign-in, so a tool call cannot change who it is. The repo has examples for the Claude Agent SDK, the OpenAI Agents SDK and LangGraph.

How is Inhold different from a vector database?

A vector database stores and searches. Inhold sits in front of the store and decides, per call, whether this agent may read this item for this purpose, then logs the decision. It also labels PHI at write time and exports an evidence pack for the reviewer.

Is Inhold open source?

Yes. Inhold's code is Apache-2.0 licensed and goes public on GitHub on 9 Nov 2026. Paid plans cover the install in your customers' accounts and support.

Can I use Inhold today?

Partly. Inhold v0 runs on one machine with synthetic hospital data. The install in a customer's AWS account is being built now, and we are taking three design-partner pilots.

One stuck deal

Bring the reviewer's questions

Book a call with me. We will go through the questionnaire and say which parts Inhold answers, which need the AWS install, and which your team still owns.