OrgKernel Agent Trust Layer
Enforce cryptographic identity, least-privilege execution, and verifiable audit trails at the agent tool boundary.
Tokens carry tool allowlists, immutable parameters, numeric bounds, and expirations, while identities can be suspended or revoked, providing strong evidence of least-privilege design. The README also says private keys are returned once and not persisted, and it documents audit flows, denied-action logging, and early token invalidation. Deductions apply because no complete user-confirmation or approval protocol is shown; examples may place tool parameters and outcomes into audit records without redaction, access-control, retention, or encryption guidance. Dependencies have minimum versions but no lockfile, upper bounds, vulnerability scanning, or dependency-mitigation process, and SECURITY.md excludes third-party dependency vulnerabilities. Metaprise attribution and contact channels are clear, but publisher identity remains unverified by the curated registry.
Python requirements, package metadata, core modules, and examples are broadly aligned, common dependencies and database extras are declared, and denial or integrity-check messages are illustrated. The major deduction is an internal inconsistency: the README says governance cannot be bypassed and has no bypass path, while the integration example depends on application developers wrapping every tool call and shows no mandatory interceptor. The README marks SSO/SCIM as upcoming, whereas SECURITY.md lists those integrations within reporting scope. Comprehensive failure taxonomy, recovery guidance, and dependency-unavailability handling are not shown.
Developers, system administrators, and enterprise scenarios in finance, healthcare, insurance, and legal contexts are described thoroughly, with service-layer, FastAPI, and multiple agent-framework integration patterns. Boundaries distinguish the three available modules from planned capabilities, but the non-bypassable claim exceeds the wrapper evidence and SSO/SCIM status is inconsistent. Trigger points are specified as checks before and audit appends after tool calls, although coverage depends on integrators. Python 3.10+ and three database options support environment fit, but deployment, key management, migrations, and production configuration are underdocumented.
The README has strong organization across architecture, security, quick start, API, schemas, and framework integration; naming conventions and 27 endpoints are concrete. Installation covers editable source installation but omits package-release installation, migrations, environment configuration, production deployment, and upgrades. Apache-2.0 is fully supported by both the license text and project metadata. Pyproject declares version 1.0.0, Beta status, and a changelog link, but no changelog content or release policy is supplied. Authors, maintainers, security email, and response targets are identified, while the unknown publisher identity and main-only support leave limited evidence for long-term ownership and stable update paths. There is no dedicated FAQ and little candid limitation documentation.
The service API, REST endpoints, curl sequence, and generic tool wrapper are directly usable integration artifacts, and combining identity, granular authorization, and verifiable auditing offers clear marginal value over ordinary orchestration. Deductions reflect that the examples are not a complete production solution: mandatory interception, audit access controls, and operational processes remain the adopter's responsibility. Self-hosting, no API key, and no phone-home can reduce vendor costs, but database operations, CA-key custody, universal tool wrapping, and audit storage costs are not quantified or deeply addressed.
Several claims map to named interfaces, fields, endpoints, algorithms, and configuration, including Ed25519, SHA-256 chaining, token bounds, and dependency declarations. README, pyproject, LICENSE, and SECURITY.md provide some corroboration for identity, licensing, and the core product position. Deductions apply because no core implementation files, tests, changelog, or independent material are supplied to corroborate strong security assertions. Statements such as non-bypassability, use across every deployment, compliance-grade evidence, and prevention of attacks are not clearly separated from inference or marketing, and some conflict with the shown integration model or roadmap status.
- The non-bypassable claim is not established by the shown architecture; generic integration relies on developers installing the wrapper at every tool boundary, so omitted calls may evade scope checks and auditing.
- Audit examples record tool parameters and outcomes, but the materials do not specify sensitive-field redaction, log access control, encryption at rest, retention, or deletion governance.
- Because the service generates and returns private keys once, production adopters should separately verify CA-key protection, transport security, rotation, backup, and disaster recovery.
- Dependencies use open-ended minimum versions without supplied locking or vulnerability-management evidence; resolved dependencies should be independently reviewed before security-critical deployment.
- SSO/SCIM are upcoming in the README but appear within SECURITY.md scope; adopters should confirm which components actually exist in this revision.
- This conclusion is based only on the supplied static files; no code was executed, cryptographic implementation tested, or runtime enforcement verified.
What does this agent do, and when should you use it?
OrgKernel is a self-hosted Apache 2.0 Python trust layer that authenticates agents, constrains their permissions, and records verifiable execution histories. Its three available core modules are AgentIdentity, ExecutionToken, and AuditChain, providing Org CA-signed Ed25519 identities, instance- and mission-scoped execution tokens, and SHA-256 hash-chained audit records. It exposes both asynchronous Python service classes and 27 REST endpoints mountable in FastAPI, with persistence through SQLAlchemy Async to PostgreSQL, MySQL/MariaDB, or SQLite. Its execution model places check_scope() before a tool call and append() after an allowed or blocked attempt, while verify_integrity() detects deleted, altered, or reordered records. OrgKernel does not build or orchestrate agents; it wraps the tool layer of LangGraph, CrewAI, AutoGen, or a custom agent loop. Adopters should distinguish available primitives from roadmap items: mission lifecycle, tool gateway, policy engine, authority graph, data classification, SSO/SAML, and SCIM are not presented as currently available.
A typical flow begins with AgentIdentityService.submit_csr() or issue_from_csr(), using an agent name, organization, requested organizational unit, public key, and purpose. The service issues an Org CA-signed certificate, returns the private key PEM once during issuance, and persists an identity record without the private key. A verifier can call request_challenge() to create a one-time nonce with a five-minute TTL and verify_challenge() to check the Ed25519 response, certificate status, and expiry. ExecutionTokenService.mint() creates an Org CA-signed, time-bounded token for an agent_id and mission_id; the token can carry a tool allowlist, exact-match immutable_params, and numeric bounded_params. ExecutionTokenService.check_scope() evaluates the token, caller identity, requested tool, and parameter constraints and returns an allowed or blocked result. AuditChainService.initialize() creates a chain with a genesis IDENTITY entry, append() records execution or compliance events, close() closes it, and verify_integrity() recomputes hashes while checking sequence and prev_hash continuity. Applications can call these services directly or mount orgkernel.pyapi.router under /orgkernel for the documented identity, token, and audit endpoints.
- A financial, healthcare, insurance, or legal platform team needs replayable, independently verifiable evidence for every agent tool action.
- A platform engineering team already using LangGraph, CrewAI, AutoGen, or a custom loop wants one identity and authorization layer at the tool boundary.
- A security team needs to issue a short-lived token for one mission that permits only named tools and caps numeric parameters such as transaction amounts.
- A compliance investigator needs to retrieve activity by agent or mission and detect deleted, modified, or reordered audit entries.
- An enterprise wants to operate the trust layer on its own infrastructure using PostgreSQL, MySQL/MariaDB, or SQLite without a hosted service key or phone-home dependency.
What are this agent's strengths and limitations?
- The DualToken model requires both an organizational identity credential and an instance-scoped execution token, with token.agent_id checked against the caller.
- Execution tokens support tool allowlists, exact immutable parameters, numeric bounds, signatures, and expiration rather than relying on permanent shared API keys.
- Audit entries use content hashes, prev_hash links, and continuous sequence IDs to detect deletion, modification, and reordering through an integrity API.
- The same core is available as asynchronous Python services and 27 FastAPI REST endpoints, with three documented relational database options.
- The tool-boundary pattern is orchestration-framework agnostic and is explicitly described for LangGraph, CrewAI, AutoGen, and custom loops.
- Adopters must modify every relevant tool execution path to perform the pre-call scope check and synchronous audit write; integration is not automatic.
- The issuance example returns an agent private key only once, so operators must design secure key receipt, storage, and lifecycle procedures.
- Production use requires operating the Python service, an Org CA, and a database; no container deployment, hosted offering, or complete production topology is documented.
- Mission lifecycle, tool gateway, policy engine, authority graph, and data classifier remain roadmap capabilities and should not be treated as implemented.
- SSO/SAML 2.0 and SCIM 2.0 are roadmap items. Although the repository description mentions enterprise federation, the README's capability status does not show them as currently available.
How do you install or deploy this agent?
Python 3.10+, Git, and a selected database driver are required. Run:
git clone https://github.com/MetapriseAI/OrgKernel.git
cd OrgKernel
pip install -e ".[postgres]"Replace postgres with mysql or sqlite as needed. PostgreSQL is described as recommended, while SQLite is intended for local development. The installation requires network access to clone the repository and obtain Python dependencies. Before using the services, assign the appropriate SQLAlchemy async database URL to async_engine.url and run await init_db(). No OrgKernel API key is required because the service runs on your infrastructure.
How do you use this agent?
For direct library use, import AgentIdentityService, ExecutionTokenService, and AuditChainService from orgkernel.services and construct them with an AsyncSession where required. Create an AgentIdentityCSR and call identity_svc.issue_from_csr(csr). Then create an ExecutionTokenCreate with agent_id, mission_id, execution_scope, any parameter constraints, and a future expires_at, and pass it to token_svc.mint(...). Before every tool invocation, call token_svc.check_scope(...) with a ScopeCheckRequest. If the check fails, prevent execution and append an EXECUTION_tool_blocked event; if it passes, execute the tool and append an EXECUTION_tool_call event. Initialize the mission audit chain with audit_svc.initialize(...) and validate it with audit_svc.verify_integrity(...). For HTTP use, create a FastAPI app, configure async_engine.url and init_db() during startup, and call app.include_router(router, prefix="/orgkernel", get_db=get_db) to mount the documented 27 endpoints.
How does this agent compare with similar options?
Compared with LangGraph, CrewAI, or AutoGen alone, OrgKernel does not replace orchestration; it adds verifiable identity, scoped authority, and hash-chained auditing to their tool execution paths. Compared with per-agent API keys, ExecutionToken provides mission scope, parameter constraints, a cryptographic signature, and expiration. Compared with ordinary application logging, AuditChain links records with SHA-256 hashes and exposes integrity verification, although the adopter must still route every execution path through the checks and synchronous audit writes.