Inhold answers for a security reviewer, on one page

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. Your vendor's agent receives whatever policy lets it read, so if that agent runs in the vendor's account, that data leaves yours.

The CI egress test runs the demo with outbound connections blocked. It also checks that agent sign-in attempts the regional AWS STS endpoint, with that connection blocked by the test. It does not test a real STS response or prove the AWS network controls. The network controls ship with the AWS install.

Inhold staff have no account in your install and no entry in your bundle. The vendor's agents read only what your bundle grants them, every read is logged, and those grants can include PHI.

Your policy bundle, a JSON document your team owns. Every read is checked on actor, purpose and data label. After the first boot, changes take effect only through the policy API, which logs them.

Each call runs under a purpose. Search leaves out labels outside it and logs the filter it applied; a direct read of such an item is refused and logged.

No. Identity is fixed at authentication. A requested purpose is refused unless the bundle registers it for that identity, and on MCP the purpose is fixed for the session.

Every policy decision, allowed or denied: who, which action, which object, which labels, which purpose, which policy version, which engine hash and which session id. One audit chain is kept across connections.

The session id groups one agent run's rows and is never used in a decision. The MCP server sets one per process; over REST the caller sends it.

Not by the application: rows are append-only and hash-linked. Anchors outside the database are written when the store is created, every 100 rows and at each export, and are signed when an anchor key is configured. On one machine they are kept as write-once files on the host and in every pack. Verification fails on truncation or rewrite below an anchor, and refuses to pass with no anchor.

This detects a rewrite only if the admin cannot also reach the anchors. In v0 on one machine the anchors sit on the same host, so keep each pack you receive and check the next one against it. An S3 Object Lock store, signed with a KMS HMAC key, is built in code and inhold anchor writes the heads there. It has not been run against a real AWS account. Rows after the newest anchor are not covered, and read-only gateways leave heads pending until inhold anchor runs.

Deny rows are in the audit export with the reason, and the summary counts them by action.

The correction is stored with a diff and becomes a draft skill. A named approver must approve it before any agent uses it.

Only roles granted policy change in the bundle. Each change is logged with the new bundle hash.

Every audit row carries the SHA-256 of the active bundle, along with the engine hash and the session id.

People use OIDC with a pinned JWKS and one stable identity claim, oid by default. Agents use an AWS IAM role with a presigned sts:GetCallerIdentity request. The mTLS fallback is not built.

OIDC is tested with generated signing keys and IAM sign-in with a stand-in for STS, not yet against a real identity provider or AWS account. Static tokens are laptop-only. On REST and MCP over HTTP they need a flag and are refused in AWS mode; stdio MCP still uses a static token with no flag.

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. Any later feature that calls a model would call your endpoint, off by default, with each call audited.

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

The control map is in v0 and covers parts of 164.312(a) to (e) and minimum necessary. Six rows are in v0, two are designed and one is a gap; see the HIPAA map.

Inhold maps what it does to eight lines of 45 CFR 164.312 and to the minimum necessary standard. It does not yet map emergency access, automatic logoff or the (e)(2) specifications. The map is a draft for your reviewer, not legal advice.

A STRIDE model of the gateway, store, policy and audit, including prompt injection that tries to read another purpose's data.

Not yet reviewed by an outside security tester.

MANIFEST.json lists each file's SHA-256, the chain head, the export anchor and the policy hash, but it is unsigned. inhold verify-pack checks the chain against an earlier pack you kept, so a pack cannot vouch for itself and your first pack is the one you start trusting from.