RENKER

Trusted infrastructure for autonomous AI

RENKER

Platform overview Three projects · one shared core ACT · LEARN · SECURE Revised 2026-08

Capability shouldn't imply permission.

AI systems are becoming capable of acting — operating a computer, sending messages, running experiments. RENKER builds the layer that makes those actions controllable, verifiable, and accountable: the decision of what an agent may do lives in a small, deterministic, auditable layer outside the model, reading only trusted grants — never the agent's own claims.

§ 1

Three problem domains, one foundation

Each project answers one concrete question about autonomous AI. All three consume the same identity, capability, permission, policy, and audit primitives — so the security logic is written once, not reinvented per product.

ACT

A desktop AI agent that can operate your computer — with a capability-security layer between what it wants to do and what it's allowed to do.

personal use
guard integration (partial)
LEARN

An autonomous research architecture where every claim carries an explicit evidence category — experimental, predicted, or literature-derived — enforced in code.

Phase 0 prototype
simulated data
SECURE

Content-blind secure-communication infrastructure — the relay only ever sees ciphertext and connection metadata, never message content, whether the endpoint is a person or an agent.

E2E messaging prototype
content-blind relay
§ 2

Every claim is checked against code

Not another AI pitch. Each statement is traceable to a README, a test run, or a CI workflow, and marked for how finished it is. The full accounting — including the gaps — lives in one document.

ClaimStatusEvidence
Authorization decided outside the model REAL evaluate() returns ALLOW / DENY / REQUIRE_APPROVAL from stored grants only; 89 passing tests in renker-core-authz.
Tamper-evident audit log REAL SHA-256 hash-chained log with a runnable verify(), covered by tests.
Capability enforcement in the desktop agent PARTIAL Rencora's renker_guard.py integrates the core where installed; not yet the enforced path for every action.
Post-quantum messaging handshake PARTIAL RenkerVault handshake combines X25519 + ML-KEM-768; the ongoing ratchet is not PQ-secured (documented).
Autonomous research against real lab hardware PLANNED Continuum is Phase 0 on simulated data; evidence-tagging is enforced in code today, hardware is a later phase.
Independent third-party security audit NONE No RENKER project has had an external audit. Internal hardening reviews are documented per repo.
  • NO OVERCLAIM. Where a capability is partial or planned, the copy says so — a security claim you can't falsify isn't worth much.
  • LIMITS IN THE OPEN. Every repository README carries its own "what this does not protect against" section.
§ 3

The most-verified piece is open source

The platform's authorization core ships publicly and independently, so anyone can install and test it. It is the verifiable version of the shared foundation.

88
passing tests
0
runtime dependencies
SHA-256
hash-chained audit
Apache-2.0
license

renker-core-authz decides whether an agent's requested action runs — from trusted grants, never from what the agent claims — and records every decision in a tamper-evident log.

pip install git+https://github.com/sebastianrenker/renker-core-authz
formatlinttypestestsbuilddependency-audit

Verified 2026-08-11 — pytest: 88 passed, 1 skipped. From source today; PyPI planned. Repository ↗

§ 4

How it fits together

Three projects over one shared foundation, whose authorization slice is public. Every box maps to a repository.

§ 5

Documentation

Each project documents its own design and security model in depth. This is the index — architecture, threat models, and honest limits, straight from the repositories.

ACT
desktop agent
trust boundary · DPAPI keys
LEARN
Phase 0 research
evidence-tagged claims
SECURE
E2E messaging
Double Ratchet · PQ hybrid
CORE
shared foundation
proprietary (open-core)
CORE
public authz core
Apache-2.0 · 0 deps
DEMO
authz securing an agent
MCP · prompt-injection
VERIFY
evidence-driven agent verification
executed checks, not claims · MIT
OPS
token-cost measurement layer
concept phase · provider-reported · MIT
§ 6

Scope & stance

The discipline is deliberate — it matches what the repositories state about themselves.

It is

  • Infrastructure for one narrow, real problem: making autonomous AI actions controllable, verifiable, accountable.
  • Explainable — every decision a component makes should be inspectable.
  • Honest about maturity: prototypes are called prototypes.

It is not

  • An AGI project, or a claim to approach general intelligence.
  • "Unhackable" — every project ships a documented security model with known limits.
  • A claim to revolutionize an industry.
§ 7

Project sites

One page per open-source project: what it does, and what it honestly does not do.

Writing: Guardrails outside the model — why the authorization decision belongs outside the LLM.

  • renker-core-authz — Deterministic authorization and tamper-evident audit for AI agent actions
  • renkervault — Post-quantum E2EE chat prototype with a content-blind relay
  • continuum — Continually learning research-system prototype (Phase 0)
  • renker-swarm — Free, self-throttling multi-provider agent orchestrator
  • custos — Proof gates for AI coding agents
  • selfproof — Evidence ledger for AI-written code (pre-release)
  • rencora-public — Voice-driven holographic AI assistant