OrgKernel: Ed25519 Agent Identity and Hash-Chained Audit, Reviewed

The gap OrgKernel targets: agents that cannot prove who they are

Agent frameworks handle orchestration. The README states plainly that LangGraph, CrewAI and AutoGen help you build and orchestrate agents but do not answer who an agent is, what it may do, what it did, or who authorized it. OrgKernel is positioned as the layer that answers those four questions, and the intended audience is engineers deploying agents in environments where an audit trail has to survive scrutiny: banking, healthcare, insurance and capital markets are named as the deployments behind the Metaprise AURA platform. The library is also offered standalone, with the README claiming no API key, no phone-home and no vendor lock-in. That combination matters because the usual alternative in this space is a hosted governance product, and OrgKernel's pitch is that the same primitives can run on your own infrastructure under Apache-2.0.

DualToken: identity plus instance-scoped execution token at the call site

The core mechanism is the DualToken model. At execution time an agent presents two things: an organizational identity credential and an instance-scoped execution token. Both must validate before a tool call proceeds. Identity is an Ed25519 keypair issued through a CSR flow against an Org CA, with a lifecycle covering suspend, revoke and reactivate. The execution token is where the interesting restriction lives: it carries tool allowlists and immutable, bounded parameters, and it is signed with Ed25519 to prevent token grafting, meaning an attacker cannot lift a token from one context and present it in another. Tokens are described as mission-scoped and time-bounded, so authority expires rather than persisting. The README also describes authorization as a graph rather than a boolean, with four layers (organization, department, role, instance) where any layer's denial blocks execution. Its worked example is an agent trying to spend $10,000: the request is blocked at the token scope check because purchasing authority at that amount sits with the department lead, and the denial context is already recorded in the audit chain.

The audit chain is the part worth scrutinising

Audit is split into three layers: IDENTITY, EXECUTION and COMPLIANCE, persisted to PostgreSQL, MySQL or SQLite with SHA-256 hash chaining. The integrity claim is specific and testable: any deletion, modification or reordering of entries breaks the chain and is detected by the integrity API. That is a stronger property than application logging, which the README characterises as a log you hope is complete. It is also a weaker property than it may first appear. Hash chaining detects tampering after the fact; it does not prevent it, and it does not by itself prove that an event was recorded at all. An operator with write access to the database and the chain head can truncate the log and rebuild a consistent chain from an earlier point. The README does not describe anchoring to an external timestamping authority or a published chain head, so the trust boundary is the database plus whoever administers it. For internal compliance review that may be sufficient. For adversarial or regulatory evidence, ask about anchoring before assuming the chain settles the question.

Getting it running: what the README actually specifies

The README names Python 3.10 or later, FastAPI and PostgreSQL as supported, with MySQL and SQLite also listed for persistence. It counts three core modules and 27 REST endpoints. The architecture diagram shows the identity flow through AgentIdentityService: a CSR is submitted via submit_csr(), which validates for duplicates, then issue_from_csr() generates an Ed25519 keypair server-side and signs the certificate with the Org CA. That is the level of detail the material provides. There are no installation commands, no environment variable names, no sample request bodies and no configuration keys in the supplied text, and the homepage field is empty. If you are evaluating this for adoption, the first practical step is to read the repository directly for the dependency list and the FastAPI app entry point, because none of it is in the README excerpt. Treat the absence of a quickstart as a signal about documentation maturity rather than as a defect in the design.

What is shipped versus what is promised

The capability table is unusually honest about this split, and it is the most useful part of the README for a decision. Three capabilities are marked Available: cryptographic identity with the full lifecycle, scoped execution tokens, and the three-layer hash-chained audit trail. The roadmap covers mission lifecycle, tool gateway, policy engine, authority graph, data classifier, SSO/SAML and SCIM. Note the mismatch with the repository description, which lists enterprise SSO/SCIM federation as if it were present. It is not, according to the project's own table. The same applies to the authority graph: the README's framing of authorization as a four-layer graph is persuasive, but the component that would implement it is listed as upcoming. Today you get identity, tokens and audit. You do not get a policy engine that evaluates those four layers declaratively, which means the graph logic has to live in your application code. That is a real gap between the conceptual pitch and the shipped surface.

Where OrgKernel is the wrong tool

OrgKernel sits in the execution path, so it can only govern what passes through it. Any tool call that does not go through its scope check is outside its reach, and the README's claim that there is no code path around the checks holds only for agents wired into the library. A shell tool that an agent invokes outside the governed path, or a credential the agent already holds, is not covered. The second limitation is operational: the audit trail is only as good as the storage behind it, and running SQLite in production for a compliance-grade log is a poor fit for concurrent agent workloads. Third, the project has no releases retrieved and the last push is dated 2026-07-06, so there is no versioned artefact to pin and no changelog to read. If your requirement is a stable, versioned dependency with a support window, this is not that yet. If your requirement is a hosted control plane with a support contract, OrgKernel is explicitly the opposite of that.

Compared with an API gateway and a secrets manager

The obvious alternative is the combination most teams already run: per-agent API keys in a secrets manager, plus a logging pipeline. The difference is not cosmetic. A key in a secrets manager is permanent until rotated, unscoped beyond whatever the upstream service enforces, and shareable without leaving a trace of the sharing. OrgKernel's execution token is bounded in time, restricted to a tool allowlist, and signed, so a copied token fails validation outside its instance. The audit difference is similar in kind: a logging pipeline writes records an operator can edit, while the hash chain makes edits detectable. What OrgKernel does not replace is the secrets manager itself, since the Org CA private key and any upstream credentials still need somewhere to live. Nor does it replace an API gateway, which handles network-level concerns OrgKernel does not address. The honest framing is that OrgKernel adds a layer; it does not remove the ones you have.

Licence, maintenance and what to check before you commit

The licence is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent-grant terms. That is a permissive licence, and it means forking is a genuine option if the project stalls, which matters given that no releases were retrieved and the last push is recent but unversioned. Maintenance cost is harder to judge from the supplied material: there is no changelog, no release cadence and no contributor information in the README. The upgrade cost is therefore unknown, and the practical consequence is that you should vendor or pin a commit hash rather than track main. The one thing the README does make clear is that OrgKernel is the trust foundation of the Metaprise AURA platform, so the project has a commercial consumer and is unlikely to be abandoned silently. That is not a guarantee, and it is not the same as a support commitment. Read the cryptography before you trust it: the CSR flow, the server-side keypair generation in issue_from_csr(), and the signing path are all in the repository, and they are the parts where a mistake would be expensive.

Editorial conclusion

Adopt OrgKernel if you run Python agent frameworks such as LangGraph, CrewAI or AutoGen and need verifiable identity, per-mission scope, and an audit log whose integrity can be checked independently. Do not adopt it if you need policy enforcement, SSO or SCIM today, since those are listed as roadmap items rather than shipped features. Before committing, verify three things against the repository: what actually backs the integrity API, whether the audit storage layer supports your database, and how the Org CA private key is generated and stored.

Official sources

1. Issues
2. License: Apache-2.0
3. MetapriseAI/OrgKernel on GitHub
4. README