HERMAI.IO / A GRAINWORK PROJECT Working alpha

HERMAI

Give the agent authority to send. Keep control of the account.

Hermai is for teams that need a production agent to send customer messages without giving it control of the sending account. Your team sets recipient rules, volume limits, expiration, and revocation. When that authority ends, the next send stops.

The working alpha proves this control on Hermai's own transport today. Connections to email, SMS, and other production providers are not built yet.

See how the control works → Try the live refusal →

Hermai takes its name from the boundary stones of ancient Greece. The idea is simple: mark the line before it gets crossed.

The control

A policy cannot stop a send. The sending path must enforce it.

In the proposed production layer, your team keeps control of the sending account and routes each scoped customer-message attempt through Hermai. Your rules decide who the agent may contact, how often it may send, when its authority ends, and when access is revoked.

The working alpha proves four parts of that decision today:

Your rules

The agent cannot raise its own limit

Your team sets recipient rules, volume limits, expiration, and revocation. The agent can operate inside that boundary, not rewrite it.

A hard stop

The next send is refused

When the allowance is gone, the next attempted send stays unsent and returns an exact reason plus the next available action.

Retry-safe

Retries do not buy more capacity

Repeated requests return the original result. In the reference sender, crashes and races do not turn a limit of four into five.

Revocable

Access ends with the job

Revocation or ordinary expiry disables the agent's sending access. Work already accepted by the current transport cannot be recalled.

Proof the limit survives

Used sends survive retries and rule changes. Revocation stops the next attempt.

The working alpha records the limit with the send, so replaying the same request cannot spend twice. Reissuing the agent's authority keeps its prior usage instead of resetting the meter. Revoking access refuses the next attempt before the current transport accepts it.

Current proof

The agent cannot reset its own history.

Retries return the original result. New authority inherits prior use. Revocation disables the next pre-submission send.

Current boundary: this behavior is proven on Hermai's own transport. Production provider connections are not built.

Test receipt: 503 tests passed on 31 August 2026, including replay, reissue, revocation, and crash recovery.

Run the live limit test →

Limit set3
First message2
Second message1
Third message0
Fourth attemptrefused

Paid design-partner review

Start with one customer workflow.

For teams whose production agent sends customer messages without per-message approval, or whose launch is blocked until security can control that path.

Scope One provider or central sending service. One workflow. Written production and security criteria.
Control The agent would lose direct access to the sending account. Every in-scope attempt would pass through the same enforceable rules.
Proof now The working alpha enforces send limits and revocation, preserves those limits across retries, and expires access on Hermai's own transport.
Commercial path $25,000 → $50,000 The engagement fee is credited toward the annual production contract when the agreed criteria are met.

Seeking three paid design partners

Bring the workflow security cannot yet approve.

Hermai is selecting three teams operating a production AI agent that sends customer messages without per-message approval, or preparing a launch blocked on outbound-message control.

The design-partner engagement is $25,000, credited toward a $50,000 annual production contract if the agreed criteria are met. These terms apply to the first cohort and may change afterward.

No payment is due with this request or the technical review. Hermai invoices only after three teams pass review, align on the same provider and scope, and agree to the engagement. If that cohort does not form, no invoice is issued and no engagement begins.

Hermai is built and led by Ryan Katzman at Grainwork.

Initial build
One provider, one workflow, and written production and security acceptance criteria.
Cohort condition
The first integration is selected only after three approved teams share a provider or central sending service.
What this is
Paid product development, not advisory work or an unpaid pilot. Submitting does not reserve a place or commit either company.

Request a Hermai design-partner review

Briefly describe the production workflow, what makes the issue urgent, and your role in the decision. We use it to decide whether Hermai fits your workflow.

What does the agent send, to whom, and through which provider or internal message service?
Describe the incident, control requirement, audit, insurer request, launch, or customer commitment creating the deadline.

Do not include passwords, API keys, access tokens, customer messages, customer personal data, or raw security artifacts. Hermai uses this business information only to assess and manage a potential design partnership. Read the privacy notice for design-partner inquiries.

If the form is unavailable, email hello@hermai.io.

Technical appendix

Exact mechanisms, evidence, and limits.

Security and implementation teams can review the exact mechanisms, operating limits, and failure boundaries below.

Sender authority and crash boundary

An Ed25519 signature covers a canonical-JSON warrant under postage.agent.warrant.v1. The verifier resolves the operator's root key from the directory rather than trusting a key supplied beside the warrant. Expiry is mandatory and capped at 90 days; a warrant with no durable operator-side record fails closed as revoked.

The warrant-meter increment and postage hold are committed by one durable event in one SQLite BEGIN IMMEDIATE transaction. Retries using the same idempotency key return the original response and consume nothing further. Reissuing a warrant inherits the prior meter instead of resetting spent capacity.

This is sender-side control. It bounds a cooperating delegated actor and the blast radius of a leaked agent credential. It does not bind an operator running modified sending software.

Raw refusal contract

A rolling-window ceiling returns 429 with Retry-After. A lifetime ceiling or empty wallet returns 409. Expired, revoked, missing, and recipient-policy failures return 403. The body carries the exact reason and remedies so the caller never has to parse prose. 

ok: false
code: "WARRANT_WINDOW_EXHAUSTED"
message: "This agent has used its whole send
  allowance for the current window. The next
  unit frees at 2026-08-29T04:40:07.911Z."
remedies: ["wait_until",
  "ask_operator_to_raise_limit"]
Exact signed authority fields

At most one warrant is live for an agent. Replacing it revokes the predecessor, and the agent can never issue or redelegate one.

postage.agent.warrant.v1, signed payload
scope
"agent-send-authority"
operatorIdentityId
who signed, and whose postage pays
agentIdentityId
one agent, named
limits.unitsPerWindow
how many sends per window
limits.windowMs
the rolling window
limits.totalUnits
a lifetime ceiling no waiting clears
limits.maxRecipientsPerSend
the widest one batch may be
recipientPolicy
an allowlist, recipient consent, or both
expiresAtMs
mandatory and bounded
redelegable
false
Postage, custody, and the current transport

The local alpha separately persists a directory, allowance issuer, postage ledger, custody coordinator, four independently keyed relay roles, and the client store. They run in one process on one host, so those signatures are protocol evidence rather than independent Byzantine fault domains.

The postage ledger sees a grant, holder signature, spend sequence, and opaque envelope commitment. It does not receive the sender, recipient, ciphertext, or warrant rules. The sender encrypts to the recipient's active devices; three relay stage votes are required before the ledger irreversibly commits the grant, and three custody votes make the envelope visible.

The recipient archives locally before its signed receipt enters a durable outbox. Delivery and expiry use a write-once coordinator proposal plus durable relay locks so exactly one terminal outcome is certified.

Evidence and hosting boundary
Test suite
503 passing
Dependencies
zero
Reference service
loopback only
Hosted gateway
not yet

Test count from an actual npm test run on 31 August 2026; the most recent coverage run, on 30 August, reported 97.7% of lines. The suite includes seeded property fuzzing, crash injection across the send path, and restarts that close and reopen every database mid-flight.

A production service still needs capability rebinding, a key-custody split, enrollment controls, TLS and origin policy, rate limiting, clock authority, and process separation. The disposable sandbox closes none of those gaps.

Non-claims and permanent boundaries
  • A warrant limits one delegated agent. It does not stop an operator from opening more accounts or replacing the sender software.
  • The permit does not travel with the message. The recipient cannot independently verify the sender-side limit.
  • Postage is one condition of admission, not attention, delivery, safety, or a reply.
  • A receipt proves a device signed for ciphertext. It does not prove a person read the message.
  • Revocation stops the next pre-custody attempt. It cannot recall a message already in custody.
  • There is no token, yield, payout, or recipient payment.
  • The current encrypted-drop transport requires both sides to run it. There is no SMTP bridge.
Run the proof locally

The public demo shows the limit without an install. The same loop is available from the repository:

npm run v2:agent-demo        # full loop, including refusal
HERMAI_API_KEY=<key> npm run v2:mcp -- \
  --api-url http://127.0.0.1:8787 --account <agentAccountId>