CT Scans, Corporate Docs, and Self-Hosted Giants
Trust and control look different in every industry. A hospital needs to know that imaging data never leaves their control. A global enterprise wants AI that runs against their own data, in their own walls. A marketing team wants to send email that looks like the company—without giving the AI the keys to the kingdom. Three stories show how the same model—identity, resources, policies, and connectors—adapts to each.
Story 1: CT Scans in the Vault
Imagine a healthcare provider that wants to use AI to help radiologists. The data is sensitive: CT scans, patient identifiers, and reports. Regulations and ethics demand that this data stay under the provider's control and that access be auditable.
With HUMΛN, that data can live in a vault—storage where keys never leave the provider's designated device or enclave. Resource policies say: "For this org, core.health.ct_scan (and related kinds) go to the vault." Agents that need to read or write those kinds don't get a connection string to a PACS system. They request resources by kind; the platform routes the request to the vault connector. The vault holds the bytes; the provider holds the keys. The AI never sees raw credentials or arbitrary database access. It just sees "resource of kind X" and gets back what policy and delegation allow.
So: trust comes from "the data never left our control." Control comes from policy and keys. The agent stays the same; the storage and the authority model are what change.
Story 2: Corporate Docs in Your Datacenter
A large enterprise has petabytes of documents, contracts, and knowledge in their own datacenter. They're happy to use AI, but they will not send that data to someone else's cloud. Every connector that touches that data must run inside their walls.
The same kind-based model works. They run self-hosted connectors that talk to their document stores, their search index, and their internal APIs. Resource policies point to their store names. Their agents (or HUMΛN agents they deploy on-prem) call the same APIs: load/save by kind. The platform resolves the request to their connector in their environment. No data leaves. The "giant" stays self-hosted; the protocol and the agent code stay the same.
So: trust comes from "we never send our data to you." Control is geographic and architectural. Kinds and policies make it configurable instead of custom per vendor.
Story 3: Email Branding and Delegation
A company wants their AI to send email that looks like the company—right "From" name, right footer, right tone. But they don't want to hand the AI a raw SMTP password or full access to the entire mail system.
With HUMΛN, profile and brand live in the Resource Graph (org profile, org comms settings). The AI gets delegated capability: "you may send on behalf of this org, using these templates and this identity." The actual credentials and delivery are handled by a connector and the platform. The AI doesn't see passwords; it sees "send as the org, within these rules." Delegation is scoped; branding is consistent; audit shows who sent what.
So: trust comes from "the AI can only do what we delegated." Control is clear: we set the comms policy, we grant the scope, we see the log.
In all three cases, the same ideas show up: identity (who is acting), resources and kinds (what type of data), policies (where it lives and how it's used), and connectors (the bridge to the real system). CT scans in the vault, corporate docs in the datacenter, email with delegated branding—different industries, one coherent model. That's how we build for trust and control without asking every organization to become a protocol expert.