Agent Registration · signalprism.com

Your agent ships.
Its authority travels with it.

Enterprises are already asking what your agent is authorized to do before they deploy it. Registration gives you a governed declaration, a verifiable artifact, and a badge for your README — before they ask, not after.

signal-prism
registered · tier-2

↑ What goes in your README. What an enterprise security team sees before they deploy.

Request Early Access → Why this matters now
Why now
"You've seen this pattern before. The developers who were already compliant had nothing to do. The developers who weren't spent months scrambling."

Every major wave of software trust infrastructure followed the same curve. It started with a question enterprises couldn't answer. Then a standard emerged. Then the question became a procurement requirement.

You don't have to care about governance infrastructure for this to matter to you. You just have to want to ship your agent into enterprise environments without a six-week security review delay because nobody can answer that question about it.

What exists today vs. what registration produces

Without registration

  • A PDF on your vendor website that can be updated silently
  • A README that makes claims with no provenance
  • A security questionnaire filled out differently every time
  • An enterprise security team guessing at scope from documentation
  • No record of what was declared before deployment

With registration

  • A hash-verified artifact — immutable from the moment it's written
  • A public registration page linked from your README badge
  • A declared scope the enterprise security team can verify independently
  • A governed delegation chain traceable to a human decision
  • A permanent record that predates every action your agent takes
Who registers

Three types of builders.
One registration surface.

Solo developer
TIER 1 — FREE
You're building an agent. An early enterprise customer asks what it's authorized to do.
Tier 1 gives you an artifact ID and a badge in your README — five minutes, no cost. When the question comes, you have an answer. When it doesn't yet, you've lost nothing.
Startup or team
TIER 2 — STANDARD
Your sales team needs something concrete to hand a security reviewer. Your README badge should answer the scope question before it's asked.
Tier 2 adds declared purpose, scope, and explicit exclusions. The scope check runs at registration — not at the moment your agent tries something it shouldn't. Your security story is established before the deal review, not during it.
Platform provider
TIER 3 — FULL
You're shipping agents into enterprise environments at scale. You want to know how they actually behave in those environments — not just how you designed them to behave.
Tier 3 unlocks Provider Intelligence Access. When your agents run in governed enterprise environments, S&P accumulates a behavioral record against your declared scope. That record — the most accurate characterization of your agent's actual performance in production — is available exclusively to Tier 3 providers, with customer permission.
What registration produces

Four things. No runtime required on your side.

01
A Registration Artifact
A hash-verified JSON document written to the Agent Authority Ledger. Your identity, purpose, scope, and delegation chain — in governed, immutable form. You receive the artifact ID. The hash lives in the ledger and proves the artifact hasn't changed.
02
A Verification Receipt
At registration you receive a signed receipt containing your artifact ID, the hash, and a timestamp. Your proof is independent of our ledger. At any point you can verify the artifact against your receipt — without trusting us to tell you it's unchanged.
03
A Public Registration Page
Every artifact resolves to a human-readable page. What your agent does. What it's allowed to touch. What it explicitly won't do. Readable by a procurement reviewer, not just a developer. You control what's shown. Private fields stay private.
04
A README Badge
An embeddable badge that links to your registration page. Put it in your GitHub README. Enterprise buyers see it. Other developers ask what it means. The badge is your distribution — every README that carries it explains the standard to the next developer who reads it.
Declaration tiers

Declare as much as you want.
Never more than you're comfortable with.

Minimum
TIER 1
Solo developer
Identity and delegation. Nothing more.
Your agent is known, delegated, and time-bounded. No scope constraint enforced at registration. Lowest friction. Suitable for any developer who wants presence in the registry before they need it.
agent_id provider delegating_principal delegation_instrument expiry
Free
ALWAYS
Standard
TIER 2
Startup / team
Scope declared. Pre-flight checked.
Add declared purpose, scope, and what your agent explicitly won't touch. Scope violations are detectable before the first action runs. This is what enterprise procurement teams want to see — and what your sales team needs in a security review.
agent_id provider delegating_principal declared_purpose scope excluded_scope expiry
$29
/ MONTH
Full
TIER 3
Platform provider
Full declaration. Behavioral intelligence unlocked.
Add provider attestation, model version, and behavioral commitments — in language you write, not language we require. Tier 3 exclusively unlocks Provider Intelligence Access: governed behavioral data about your own agents running in customer environments, exported with customer permission.
agent_id provider declared_purpose scope provider_attestation model_version behavioral_commitments
$149
/ MONTH
How your declaration is protected

Two guarantees.
One of them is math.

Integrity — cryptographic

When you submit your registration payload, S&P computes a SHA-256 hash of that exact payload at the moment of ledger write. The hash is stored with your artifact in the Agent Authority Ledger.

At any point in the future — tomorrow, two years from now — anyone can recompute the hash from the artifact and verify it matches. If a single character changed, the hash wouldn't match.

This means S&P cannot alter a registration after the fact without detection. You receive a signed verification receipt at registration. Your proof is independent of our ledger. It requires trusting math, not trusting us.

Confidentiality — by design

Your private declaration fields — scope details, behavioral commitment language, model version, internal architecture — are encrypted at rest and access-controlled. S&P staff cannot read your payload in plaintext. It is never aggregated across developers or sold.

What's public is only what you chose to surface: your declared tier, your agent's purpose in plain language, your registration status, and your badge. Everything else is yours.

The declaration is a declaration, not a contract with S&P. You wrote it. We recorded it. The relationship ends there.

Registration is a declaration, not a contract. You control the language. We govern the record. S&P doesn't tell you what to commit to — it records what you chose to commit to, in governed form, in the ledger.
Privacy model

Your declaration is yours.
The fact that you made one is what the world sees.

Stays in your account

  • Your full registration payload
  • Declared scope details and excluded scope
  • Behavioral commitment language
  • Model version and internal architecture details
  • Delegation chain specifics
  • Provider attestation contents

Visible on your registration page

  • That a governed declaration exists and is on file
  • Your declaration tier
  • Your agent's declared purpose in plain language
  • Registration date and expiry
  • Hash verification status — "verified ✓"
  • Your embeddable badge
Signal Prism does not publish your registration payload, aggregate it across developers, or sell it. We record what you declared. You control what's shown.
The artifact

What gets written to the ledger
when you register.

agent_authority_ledger  /  ara_4f9e2c1a88b3  ·  tier-2  ·  verdict: approved
{
  "artifact_class":       "agent_registration",
  "artifact_id":          "ara_4f9e2c1a88b3",          // ← your artifact ID
  "agent_id":             "your-agent-v1.0",
  "provider":             "your-company",
  "declaration_tier":     2,
  "declared_scope":       ["data.read", "report.generate", "notify.send"],
  "excluded_scope":       ["data.write", "secrets.read", "deploy.*"],
  "verified_delegation":  true,
  "registration_verdict": "approved",
  "legitimacy_baseline":  "established",
  "valid_until":          "2026-11-03T00:00:00Z",
  "hash":                 "sha256:9f4a2b8e1c7d...",   // ← tamper-evidence seal
  "ledger":               "agent_authority_ledger",
  "emitted_at":           "2026-05-03T14:22:11Z"
}

The hash lives in the ledger. You receive the artifact ID and a signed verification receipt. Your proof is independent of our record.

What developers declare

Real declarations.
By agent type.

The excluded scope is always the most important part. Anyone can say what an agent does. Saying what it will never do — in governed, hash-verified form — is what stops an enterprise security review.

data-pipeline-agent · tier-2 · verdict: approved
"agent_id":          "data-pipeline-agent-v2",
"declared_scope":    [
  "data.read",
  "report.generate",
  "notify.send"
],
"excluded_scope":    [
  "data.write",           // ← cannot modify source data
  "data.delete",
  "secrets.read",
  "deploy.*",
  "billing.*"            // ← cannot touch billing systems
]

The excluded scope is what enterprises read first. A governed, hash-verified exclusion list is the difference between a vendor claim and a verifiable declaration.