A status inside the provider that performed the action.
Control for software agents
Approve one action. Verify the result.
Polymodum checks one exact action against your rules, uses the permission once, and returns a signed receipt.
The problem
A log is not permission.
Most logs are written after an agent acts. They may show what a system recorded, but not that the exact action was allowed first. Polymodum checks before dispatch.
A record another verifier can check outside that provider.
How it works
One request. One permission. One receipt.
The verifier checks the disclosed action, decision, one-use state and result. It does not assume this website is telling the truth.
Describe the action
Fix the tool, recipient, input and limits before the agent starts.
Approve it once
The permission is stored and consumed when that action is dispatched.
Check the receipt
Another machine can verify the records with public keys you trust.
A signature proves what the configured system recorded. It does not by itself prove that every host, operator or real-world outcome is trustworthy.
Bounded connections
One local agent. No ambient authority.
Models can propose work, but credentials remain inside narrow service adapters. Every write must name the provider, operation, target and input before a one-use permit is consumed.
Local models
Hermes or Qwen can be exposed through a signed model manifest. The remote operator receives no Ollama credential or host access.
model.invoke / exact alias
GitHub
The public permit profile will bind repository, operation, ref and payload. Installation credentials remain outside the repository and model process.
github.issue.create / bound repo
X
The public permit profile will bind account, post body, media digest and reply target. OAuth credentials remain private deployment state.
x.post.create / bound account
Planned labels are not implementation claims. Public adapter code must never contain deployment credentials, account identifiers or private allowlists.
First application · experimental
Change mail provider. Keep your identity.
Your identity is a key you control, not an account at one company. Revoke provider B, move to C, and keep the same identity and verified history.
Encrypt
Bind the recipient and encrypted message before it is sent.
Confirm
Keep signed custody and receiver acknowledgements.
Move
Revoke one provider and choose another without becoming a new user.
What the trial does
One encrypted message. One failover. One provider switch.
Alice approves a message to Bob. C stores the same encrypted envelope while B is offline. B acknowledges it once. Bob then moves from B to C with the same root identity.
The signed action fixes the recipient, endpoint and ciphertext.
C holds encrypted custody. B accepts the same envelope once.
Bob revokes B and signs a new mailbox endpoint at C.
Checks backed by signed files
Waiting for a fresh signed replay. No result is inferred until every required receipt passes local verification.
- Signed actionWaiting for verified evidence.Checking
- Deterministic authorizationWaiting for verified evidence.Checking
- One-use executionWaiting for verified evidence.Checking
- Receiver acknowledgementWaiting for verified evidence.Checking
- Relay failoverWaiting for verified evidence.Checking
- Identity migrationWaiting for verified evidence.Checking
Experimental local trial—not Internet mail, not a reliability or decentralization claim. No independent operator, external transport, provider honesty, host integrity or real funds are proven here.
Evidence, not theatre
Passed locally is not passed on the Internet.
This page keeps those claims separate. The Explorer shows the signed records, verifier output and limits behind each status.
Awaiting a fresh, locally verified signed replay.
Zero externally qualified independent operators in this trial.
No wallet, real payment, SMTP provider or Internet delivery is used by this evidence bundle.
One public identity
The same verified release, wherever it resolves.
The public site is prepared as a content-addressed static bundle. ENS can point polymodum.eth to its CID; a classical domain can publish the same CID through DNSLink and a self-hosted gateway.
- ENS
- Contenthash → IPFS CID
- Classical DNS
- DNSLink → same IPFS CID
- Application API
- Separate, explicitly live service
Inspect the work
Read the code. Check the proof.
The reference implementation uses the Apache-2.0 license. Public links appear here only after the repository, documentation and security contact are published.
- Protocol documentRendered from frozen source
- Documentation · publication pendingDocumentation
- Security contact · publication pendingResponsible disclosure
- Service status · publication pendingOperations
- Publication recordCommitment only
Questions worth asking
What Polymodum is—and is not.
What is Polymodum?
Polymodum is a way to give software agents bounded permission and produce signed evidence of the result.
Does it make an AI agent safe?
No. It can show that a configured policy allowed or denied a disclosed action. It does not prove the agent, host, operator or real-world outcome is safe or truthful.
What does “portable proof” mean?
The evidence can be checked by another verifier with the relevant public keys. You do not need to trust this website to inspect it.
Is agent mail ready for everyday email?
No. The current agent-mail trial is a local, experimental protocol test. It is not Internet email and does not yet prove independent operators or public-network reliability.
Is this a blockchain, token or payment product?
No. Polymodum does not issue a token, announce an airdrop or provide payment, wallet or funding authority. Optional ordering and settlement references remain separate, bounded profiles.
Can I use or contribute to it?
The implementation is Apache-2.0 licensed. Review the source and contribution guidance when the canonical public repository is published. Report security issues through the configured private contact, not a public issue.