KHNUM FORGE
KHNUM FORGE
The boundaries below aren't policy language — they're how the system is built. Khnum Forge can only hold what it's architecturally allowed to hold.
Your firm's data sits alone, in its own storage under its own encryption key. We hold pointers to your secrets, never the secrets themselves. Regulated information, such as medical records, is handled on infrastructure built for it. A tamper-evident trail records every change to your governed setup, and who made it. And you govern your own policies, including who on your side can change them. How our agents behave is on the Responsible AI page.
Khnum Forge runs on managed cloud services, primarily Google Cloud. Your data is stored, and our services run, in Google Cloud's United States regions. Google patches and scales the services and verifies who signs in. Every request is checked for a valid sign-in before any work begins, and there is no server or database of ours to misconfigure.
We never run a login system of our own.
The platform is a set of Cloud Run services in the us-central1 region; durable data lives in Google Cloud Storage buckets; and every sign-in is authenticated through Firebase Authentication.
The Khnum Forge services run as managed, stateless containers — patched and scaled by Google, with no persistent host to harden.
Records live in GCS buckets with per-bucket access control — and each client's bucket is encrypted at rest under its own dedicated key, not a shared one (see Isolation below).
Identity is verified by Google. Every request carries a signed ID token that the backend validates before any work happens.
Your firm's work lives in a storage bucket of its own, and no other client's data shares it. The bucket is encrypted under a key made for your firm alone. Access inside it runs through one path scoped to a single project, so code cannot accidentally reach another project's data. A Khnum Forge administrator can switch your key off in one step, which makes your data unreadable in place, and that action is logged.
We never store one client's data alongside another's.
It all runs in one Google Cloud footprint — Khnum Forge and every client team alike. When a client is onboarded, the team that does their work is deployed into a dedicated, per-client storage bucket — named deterministically for that client (daidalos-client-<slug>). One client's deliverables, project data, and configuration never share storage with another's.
Inside a client's bucket, every read and write is funneled through a single project-scoped storage handle. The project slug is sanitized so it can't traverse out of its own folder — code can't accidentally reach a sibling project's data even within the same client.
Access to client data is gated through one narrow path scoped to projects/<project>/.
Each client's bucket is encrypted at rest under a dedicated encryption key of its own (a customer-managed key whose identity is tied to that client), not the single Google-managed key shared platform-wide. One client's key cannot decrypt another's data, and the key never resolves to the shared reference store or system infrastructure.
Because each client's data is bound to its own key, access to it can be governed at the key. A firm-administrator-only control can instantly disable a client's key — rendering that client's data unreadable in place, reversibly — or, on deliberate confirmation, destroy it (a crypto-shred, on a recoverable grace period). Every such action is written to the tamper-evident audit log. This has been exercised end-to-end and round-trip verified on a real client bucket.
You do not hand us your passwords, API keys, or credentials. You give us pointers to where the team will find them, and our governance core stores only that address. The team that does the work looks the secrets up at runtime, and an automated check blocks any deployment that appears to contain one.
We never hold your secrets, only the address of where they live.
When you onboard, you don't hand Khnum Forge your API keys, passwords, or credentials. You give it pointers — directions to where the team will find those secrets at runtime. The secrets themselves live in Google Secret Manager; our governance core stores only the address.
A pointer like sm://… names a Google Secret Manager secret; a gs://… pointer names a manifest in the client's own bucket. The actual values are resolved at runtime, by the client-scoped team that does the work — never by the Khnum Forge governance core that designed it. Same cloud, two separate roles: the architect that holds pointers, and the runtime that resolves them against the client's bucket.
Before any team definition is deployed, an automated guard scans the entire definition and refuses to ship if it finds anything that looks like a real secret value — a password, a private key, an access token, a client secret.
Some matters turn on sensitive records, such as medical evidence, and the platform runs on cloud infrastructure covered by a business associate agreement (BAA) and architected to handle protected health information. If a task must use a model outside that coverage, direct identifiers are stripped first, and the request is blocked if that cannot be done reliably. Compliance is shared, so your own obligations still apply.
We never send a request outside that boundary unless it can be reliably de-identified.
Some of the work Khnum Forge is built for turns on sensitive records — a Social Security disability matter, for instance, is a stack of medical evidence. The platform runs on BAA-covered cloud infrastructure, architected to handle protected health information (PHI) — the contractual and technical basis for processing regulated records in the cloud.
Not every vendor or model a task might use sits inside that BAA-covered boundary. So when a task has to use one outside it, direct identifiers are stripped first, automatically. And it is fail-closed: if the request can't be reliably de-identified, it is blocked, not sent. This boundary is live and has been proven in production with a real de-identification round-trip.
In-boundary work keeps the real values it's entitled to; only what would leave the boundary is de-identified.
Said plainly: BAA-covered infrastructure and a fail-closed de-identification boundary are the platform's half of handling regulated data. Compliance in any given engagement is shared — the practices and obligations on your side matter too — and any specific regulatory posture (HIPAA and the rest) should be confirmed against your own requirements before you rely on it.
Khnum Forge owns industry-level structure: the regulations, workflows, and authorities common to an industry. You own your policies and thresholds, and you decide who on your side can sign in to your portal and change them. A portal user can reach only the client data they are authorized for; anything not explicitly permitted is denied.
We never author your policies.
There are two governance owners, and the line between them is enforced in code.
Workflows, regulatory authorities, and industry knowledge shared across every client in that industry. Khnum Forge can update these; a client operator cannot override them downward.
Your own policies, thresholds, and project-level governing points — and the list of people who may sign in to your portal and change them. Khnum Forge provisions that access on your instruction; it does not author your policies.
Access is enforced at the identity layer. Each portal user carries a claim that scopes them to exactly the client(s) they're authorized for, and the backend fails closed. Onboarding, deployment, and provisioning stay with Khnum Forge operators — they are not powers a client account can invoke.
Every change to your governed setup is written to a log that nobody can quietly edit. Each record carries a fingerprint of the one before it, so altering or removing a record breaks the chain and a check shows where. A seven-year retention lock stops even an administrator from deleting or overwriting a record before that period ends.
We never write a change to the log without a verified identity attached.
Every change to the governed setup is written to an append-only, hash-chained audit log in a dedicated, separate Google Cloud bucket. Records are never modified or deleted — to correct something, a new record is written; the prior one stays in the chain.
Each record carries the SHA-256 hash of the record before it, and its own hash over its contents. That forms a chain: removing a record, or altering one mid-stream, breaks the math — and a verification pass walks the whole log and reports exactly where the break is.
The operator_id is never self-asserted. It's taken from the Firebase ID token the backend has already verified for that request.
The audit bucket carries an irreversible 7-year retention lock (a Google Cloud Bucket Lock, WORM). Each record is a write-once object and object versioning is on — so a record can't be deleted or overwritten even by an administrator until its retention period elapses.
For teams that publish externally, an independent reviewer checks every draft before it goes out and never reviews its own work. The rules it applies depend on your industry and the channel, so an email is held to email rules and a social post is not failed for something it was never required to carry.
We never let a draft go out on an auto-publish channel without passing the compliance gate.
For client teams that publish externally, an independent compliance reviewer checks every draft before it can go out — and it never reviews its own work. Which rules it applies is never fixed: the governing authorities are specific to the client's industry, drawn from a catalog that grows as we take on new regulated areas. The reviewer applies whatever binds a given industry and channel — and only where it actually governs.
By way of example — a few of the regimes governing the marketing and publishing teams running today:
These are illustrative, not a complete or fixed list. A legal, healthcare, or financial-services team would be bound by an entirely different set, surfaced from the same catalog — the mechanism stays the same; the rules are whatever the industry demands. As we onboard new regulated areas, their governing authorities come with them.
Because the binding is channel-aware, an email is held to email rules — an unsubscribe link, a physical address — while a social post is not.
Your end-user and customer data, credentials, work product, and the secrets behind your internal policies stay in your own dedicated bucket and in a managed secret store, walled off from our governance core. The team that does the work runs against your data, in your bucket, on your behalf.
We never hold your customer data, your credentials, or your work product.
All of it lives in the client's own dedicated bucket and in Google Secret Manager — within Google Cloud, walled off from the governance core. Khnum Forge holds the reference to your secrets, never the secrets themselves.