Pyloros is the governed front door between AI agents and your company's systems.
| seq | call | decision | prev | hash |
|---|---|---|---|---|
| 21 | fx.quote | allow | 9c41…e07a | 3b8d…41f2 |
| 22 | fx.trade | approval | 3b8d…41f2 | e5a0…9c13 |
| 23 | fx.trade | allow | e5a0…9c13 | 71fe…0b6d |
| 24 | ledger.read | deny | 71fe…0b6d | c2d9…a58e |
Sealed through seq 24. A signed checkpoint fixes the ledger in write-once storage.
Why Pyloros
Self-hosted. Your credentials and records never leave your infrastructure.
Credentials live in Pyloros's vault (OpenBao). Pyloros uses one only for an allowed or approved call. Agents, logs and records never see it.
A named person signs the exact call with a passkey: Touch ID, Windows Hello or a security key.
Hash-linked records, signed checkpoints, independent timestamps and an offline verifier.
How it works
A signed token names the agent and the person it acts for.
Cedar policy by group, agent and tool returns Allow, Ask or Deny.
Ask waits for a passkey signature from someone else. One call, once.
If it can't be recorded, it doesn't run.
Pyloros adds the credential and sends the call on, over MCP or A2A.
Evidence
$ pyloros-verify --checkpoints checkpoints.jsonl \ --pubkey checkpoint.pub records.jsonl checkpoints: 25 verified, last #25 at 2026-10-03T10:38:05Z chain agent:treasury-assistant: 24 records sealed through seq 24 (checkpoint 25) chain agent:treasury-assistant: OK
OK. Every record matches its chain and its signed checkpoint.
# record 16 edited, every hash recomputed $ pyloros-verify --checkpoints checkpoints.jsonl \ --pubkey checkpoint.pub records.jsonl FAIL chain agent:pricer-7: sealed history rewritten: seq 16 differs from checkpoint 3 (the change is within seq 15..16) pyloros-verify exit code: 1
FAIL. The chain looks consistent, but it no longer matches the signed checkpoint. The verifier also names where the change is.
Why recomputing hashes fails: the checkpoints are signed with a key the database doesn't hold, in storage nobody can rewrite.
Human oversight
Console
Roadmap: an audit search screen.
Desktop app
https://<pyloros>/mcp/<server> with a token.Who it's for
Agents do the work. A named person signs.
Agent output is reviewed and signed by a named person, as the FDA's April 2026 warning letter (320-26-58) requires of the quality unit. Every signature lands in an audit trail your inspector checks offline.
Built for 21 CFR Part 11, EU Annex 11 and draft Annex 22.
Agents prepare. A second person approves.
Maker-checker for agents. Trades, payments and limit changes wait for a second signature, and every call leaves books-and-records evidence.
Built for FINRA 3110, SEC 17a-4, DORA, SR 11-7 and EU AI Act Articles 12 and 14.
Control mappings are indicative and not legal advice. You validate the system for your own use.
For engineers
Each company system gets its own endpoint. Point the agent at it with a token that names the person and the agent. No SDK, no plugin.
{"mcpServers": {"tools": {
"type": "http",
- "url": "https://tools.internal/mcp"
+ "url": "https://pyloros.internal/mcp/tools",
+ "headers": {"Authorization": "Bearer <delegation token>"}
}}}# pyloros.json {"mcpServers":{"tools":{"type":"http","url":"https://pyloros.internal/mcp/tools", "headers":{"Authorization":"Bearer <token>"}}}} $ claude --mcp-config pyloros.json --strict-mcp-config
# Same URL, same header. url: https://pyloros.internal/mcp/tools header: Authorization: Bearer <token> # The demo bundle sets Claude Desktop up for you: $ make claude-desktop
# The official MCP Python SDK (2.x), Streamable HTTP client # Requires Python 3.10+ and `pip install mcp`. import httpx2 from mcp import ClientSession from mcp.client.streamable_http import streamable_http_client headers = {"Authorization": f"Bearer {token}"} async with httpx2.AsyncClient(headers=headers) as http: async with streamable_http_client( "https://pyloros.internal/mcp/tools", http_client=http ) as (read, write, *_): async with ClientSession(read, write) as session: await session.initialize() await session.call_tool("get-sum", {"a": 2, "b": 3})
# Raw JSON-RPC, for the skeptical engineer $ curl -s https://pyloros.internal/mcp/tools \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"get-sum","arguments":{"a":2,"b":3}}}'
The tool's normal result, unchanged. It was recorded in the ledger before it was forwarded.
{"code": -32003,
"message": "denied by policy",
"data": {"reason": "no_permit", …}}A standard JSON-RPC error.
{"code": -32004,
"message": "approval pending",
"data": {"approval_id": "apr_…",
"console_url": "…",
"expires_at": "…"}}The agent retries the same call, and it goes through once someone approves it.
The token names the person and the agent (user:alice → agent:pricer-7). In a company deployment, your identity provider issues it.1
Agent to agent? Call https://pyloros.internal/a2a/<agent> instead of the agent.
1 In the demo bundle, make token creates one.
| Protocols | MCP over Streamable HTTP. A2A v1.0, plus v0.3 method names. Pinned Agent Cards. |
|---|---|
| Identity | Signed JWTs with RFC 8693 delegation chains. |
| Policy | Cedar, deny by default, in an isolated engine. If it crashes, the gateway stays up. |
| Stack | Elixir/OTP, Cedar, Go, PostgreSQL, OpenBao. |
| Try it | A Docker demo bundle runs the whole flow on a laptop. It is available to design partners. Request it → |
Roadmap
Direction, not a commitment. Customers validate Pyloros for their own use.
Design partners and pilots
We work with a small number of design partners. In a demo, an agent call is held for approval, recorded, then checked by the verifier, tamper case included.
Write to us and we will set up a demo on your own agent calls.
Email hello@arxytas.com