Authorities
- Someone stands behind the decisiona team, a role, an org
- That stance needs a durable namenot a person, not a key
- Every receipt names the authoritystable ID, rotatable key
- Auditors trace back through the nameeven years later
01The Problem
When an agent moves money or approves a contract, the natural question is: on whose authority? The uncomfortable answers most teams give today are "the model" or "the service account". Neither survives a room with a lawyer in it.
People leave. Keys rotate. Vendors change. The stance that actually stands behind the decision — the team, the role, the legal entity — needs a name that outlives all of them.
02Why existing approaches fall short
IAM was built for humans and services, not for delegated, long-running agents. Signing keys work for a message but do not describe the party that meant to send it. Roles work for access but not for accountability that reads back a year later.
The gap is not authentication. It is authorship durable enough to survive change.
03The concept
An authority is a stable identity for the party on the hook — a team, a role, an organisation, or a delegate — decoupled from the signing keys that come and go beneath it. Every receipt names its authority; the authority can rotate keys without breaking the historical trail.
04How Aarmos applies it
Authorities have stable URLs, published metadata, and rotatable keys. A receipt commits to an authority ID plus the specific key that signed at that moment. Rotate the key today, and yesterday's receipts still verify with yesterday's key.
- Nameable. Say "the Payments team authority", not "key
0x7f…". - Rotatable. Key compromise is a bad day, not a broken audit trail.
- Delegable. An authority can grant scoped, time-boxed authority to another party without becoming them.
05Example
The Payments team authority signs refunds up to $10k. On Tuesday, a key is compromised. The team rotates the key and publishes the new one under the same authority.
Wednesday's receipts sign with the new key. Monday's receipts still verify with the old key, because they committed to it by fingerprint. The historical trail is intact, and the auditor's question — "who is on the hook for this refund?" — still resolves to the same team.
06Mini-FAQ
- Isn't this just OAuth for agents?
- OAuth authenticates a caller for the next request. An authority is the durable identity that stands behind years of decisions, across many callers and keys.
- Where does an authority live?
- At a stable URL you control. Aarmos publishes and verifies against that URL; the identity is yours, not ours.
- What if we rotate the authority itself?
- A rotation is recorded and linked; new receipts commit to the new authority, old receipts stay valid under the old one. See the key-rotation runbook.