Khnum Forge
Khnum Forge
The boundaries below aren't policy language — they're how the system is built. Daidalos can only hold what it's architecturally allowed to hold.
Security & Trust — the four walls, in two minutes.
Khnum Forge runs on managed cloud infrastructure — primarily Google Cloud. 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. There is no self-managed server, database, or login system to misconfigure.
The Daidalos 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.
It all runs in one Google Cloud footprint — Daidalos and every client team alike. Isolation doesn't come from scattering data across separate systems; it comes from giving each client a wall. 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>/. It's not a convention developers are asked to remember — it's the only door, and it only opens onto one room.
The wall isn't just a folder boundary — it's cryptographic. 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.
This is the spine of the whole design. Daidalos builds the team; it does not hold the keys. When you onboard, you don't hand Daidalos 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; Daidalos's 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 Daidalos 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.
And it's enforced, not just intended. 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. Pointers pass; secrets are blocked at the door.
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. Handling that responsibly starts with the ground it runs on: 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 leverage 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.
The legal substance of the question survives; the person in it does not. 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.
Industry compliance keeps content within the law. A separate, firm-wide responsible-AI policy keeps the work itself within bounds Khnum Forge holds every client to. It is a platform-level policy that sits above client policy — only Khnum Forge can set it, it is read live, and when we tighten it the change binds every client team immediately.
It governs both sides of the prompt — the human operator who briefs the team and the agents that prompt one another (an illustrator agent writing an image prompt, for instance). A request that crosses the line is stopped before anything is produced: a person is told why and guided to rephrase; an agent is bounced and made to try again with a compliant prompt.
No prompt — human or agent — may set out to replicate a named copyrighted character, a real person's likeness, or a trademark. It is deliberately tuned to allow legitimate creative range — generic, cultural, national, and public-domain references stay open (a Chinese dragon, the Statue of Liberty) — and it is checked against a standing test suite so it targets misuse, not expression.
Around that core sit the rest of the responsible-use controls running today:
There are two governance owners, and the line between them is enforced in code. Daidalos owns industry-level structure — the regulations, workflows, and authorities common to an industry. Clients own their own policies — and decide who on their side is allowed to edit or modify them.
Workflows, regulatory authorities, and industry knowledge shared across every client in that industry. Daidalos 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. Daidalos 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: a portal user can only reach their own client's data, and anything not explicitly permitted is denied by default. Onboarding, deployment, and provisioning stay with Khnum Forge operators — they are not powers a client account can invoke.
Every change to the governed layer 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 trail is tamper-evident, not merely "logged."
The operator_id is never self-asserted. It's taken from the Firebase ID token the backend has already verified for that request, so every record is attributed to a real, authenticated identity — there is no way to write an unattributed change.
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. Append-only is the design; the lock makes it enforced at the storage layer, below anyone's reach.
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.
And 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, so a post is never failed for missing something it was never required to carry. The checks match reality instead of producing nonsense findings, and nothing on an auto-publish channel goes out without passing the gate.
The isolation above adds up to one simple commitment, and it's the same whether you read it here or read the code:
All of it lives in the client's own dedicated bucket and in Google Secret Manager — within Google Cloud, walled off from the Daidalos governance core. Daidalos holds the reference to your secrets, never the secrets themselves — and the team that does the work runs against your data, in your bucket, on your behalf.