# The governed execution boundary for agentic work. Daimon resolves logical resource requests against a live registry and a human-governed identity map, then executes through the right adapter — whether the destination is a foundation-lab model, a modern API, or a legacy system. Published: 2026-07-19 Updated: 2026-07-26 ## In brief - Agents address **logical resources** — never endpoints, never credentials. - A **human-governed identity map** decides who may call what; agents cannot alter it. - Every request, decision, and result lands in the **ledger** with full lineage. ## Resource resolution :: One request model. Every system boundary. Agents address logical resources — not endpoints or credentials. Daimon resolves the request, checks the human-governed identity map, and routes it through a model or infrastructure connector. The boundary matters because **authority never travels with the request**: what an identity may do is fixed by people, outside the agent's reach. The agent's entire world is the logical contract. :::embed{component="DaimonIntegrationMap"} ::: ## Three control planes :: A living registry. Fixed authority. Extensible execution. Every capability Daimon can reach is described, permissioned, and executed by a different plane — and only one of them is allowed to change itself. ### Resource registry Daimon's Registry Agent maintains capability contracts, schemas, versions, health, provenance, and adapter metadata. ### Identity-resource map Humans statically govern which identities and roles may use which resources, actions, and scopes. Agents cannot alter it. ### Policy + approval Evaluate purpose, data classification, limits, and context; route consequential actions to a named owner. ### Credential isolation Live provider and system credentials are used only inside Daimon and never pass to an agent. ### Adapter execution Put external models, modern APIs, and existing systems behind the same logical contract through approved adapters. ### Ledger publishing Tie request, authority decision, approval, destination, usage, execution, and result to the task that caused them. ## Request lifecycle :: One request, end to end. Six stages, one governed route — whichever system answers. 1. **Discover** — The agent discovers a logical resource and its input/output contract from the registry — not its endpoint or secrets. 2. **Resolve authority** — Daimon maps the caller's identity to human-governed resources, actions, and permitted scope. 3. **Evaluate** — Purpose, data classification, limits, and current context are checked against firm policy. 4. **Approve** — Where required, a named owner reviews the supporting case and approves or rejects it. 5. **Route + execute** — Daimon selects the approved model, modern-system, or legacy-system adapter and executes with an isolated credential. 6. **Return + record** — The permitted result is normalised and returned; destination, usage, decision, and complete lineage enter the ledger. ## Connector model :: Extend the edge. Keep the contract stable. A new system is added by implementing an approved Daimon adapter and registering its logical resource contract. Transport, credentials, and system-specific behaviour stay behind the boundary. ### Foundation lab LLMs Daimon maps the approved model resource to a provider adapter, screens the outgoing data, and calls it with a gateway-held credential. It normalises the permitted response and records model, usage, and lineage. ### Modern infrastructure REST, GraphQL, SDK, event, queue, and service APIs are exposed as typed logical resource contracts. ### Existing + legacy Database views, SFTP or file drops, mailboxes, scheduled jobs, queues, and controlled wrappers can sit behind the same request model. :::embed{component="PatternFlow" steps="Implement adapter|Register contract|Human maps identities|Approve|Daimon invokes"} ::: ## Separation of responsibility :: What may evolve. What stays human-governed. What executes. Three columns, three owners — and the boundary between them is the product. ### Registry — agent maintained - Logical capability identifiers - Input/output contracts and schemas - Versions, health, and provenance - Adapter and route metadata ### Authority — static, human governed - Human and agent identities or roles - Allowed resources and actions - Scope and data boundaries - Approval and escalation requirements ### Runtime — Daimon controlled - Provider and system credentials - Physical endpoints and transports - Egress screening and execution - Result filtering, usage, and ledger events > Daimon's Registry Agent can extend and maintain what Daimon knows how to call. It cannot expand who is authorised to call it. That authority boundary remains human governed. ## Deployment boundary :: Dedicated per client. Ownable by design. Daimon is part of each client's dedicated, single-tenant Genba environment. For an Experience Seat, Genba operates a client-named tenancy that the client owns. Approved connectors can be added when the firm is ready without changing the agent's zero access to credentials. ### Experience Seat Begin with public, reference, synthetic, or sanitised material and zero production writes. ### Live connection Connect approved systems through Daimon; policy, approval, and ledger remain on the same route. ### Ownership + exit The environment, operational data, and accumulated capability remain client assets. ## References 1. [Genba Labs — secure AI operations for investment firms](https://genbalabs.com/) — operating model ## Questions and answers ### How can a regulated investment firm let AI agents act in live systems safely? Genba places its control gateway, Daimon, between AI agents and live systems. The AI agent submits structured intent; Daimon checks the firm's permissions and approval rules, executes the permitted action with credentials isolated from the agent, and returns only the permitted result. ### What is the safest way to give an AI agent system access without exposing credentials? Genba's security model starts with zero credential access for the AI agent. Daimon keeps provider and system credentials inside the execution boundary, outside the agent's context, runtime, memory, output, and logs. The agent may request an approved capability, but only the gateway can use the credential required to execute it. ### Can every AI-agent action be audited down to model calls and token usage? Yes. For every action, Genba uses Daimon to bind the calling identity, objective, source data, destination, model or adapter, input and output tokens, policy decision, named approval, system action, result, cost, and lineage into one execution record. A compliance, risk, or operations team can reconstruct what happened and why. ### Does Daimon replace identity management, secrets management, or an API gateway? No. Daimon extends Genba into the firm's existing identity, secrets, policy, and integration infrastructure rather than replacing it. It adds the agent-specific boundary that resolves structured intent, maps it to human-governed authority, obtains approval where required, executes through the appropriate control, and records the result against the originating objective. ### Can Daimon connect AI agents to external LLMs, modern APIs, and legacy systems? Yes. Genba connects through Daimon's approved adapters, placing foundation-model providers, REST or GraphQL APIs, databases, file transfers, mailboxes, queues, scheduled jobs, and controlled legacy wrappers behind the same logical request model. New systems can be added without giving AI agents endpoints or credentials. ### Who controls what an AI agent is allowed to do? People do. Genba encodes that authority in Daimon's human-governed identity-to-resource map, which defines the resources, actions, data scope, limits, and approval requirements for each human or AI identity. AI agents may discover what is available to them, but they cannot grant themselves access, widen their scope, bypass approval, or alter the execution record.