Building an Enterprise Agent Registry

Overview

Building a registry is a process problem before it's a schema problem. The definition is short: an agent is registered once it's reviewed, owned, and scoped to a stated purpose. Getting an enterprise to do that every time, for every agent headed to production, is the hard part.

Storing a list is easy. The obstacle is a process teams will follow, structured enough to capture real governance data and light enough that nobody routes around it. A registry that creates friction gets bypassed, and a bypassed registry is worse than none, because it creates a false sense of coverage.

What a registry is, and how it differs from an inventory, is covered separately. This is the build: seven steps from what qualifies as an agent through periodic review, checked against registries that already run somewhere else.

1. Define What Counts as an Agent

Before you can register agents, you have to agree on what qualifies. Too narrow and the riskiest systems slip through. Too wide and the registry fills with noise. The useful test is capability, not branding: does the system access tools, reach enterprise data, or act with some autonomy? If so, it is in scope.

In practice that pulls in a broader set than most teams expect.

• Internal agents built by your own teams.
• Third-party agents procured from vendors and granted access to your systems.
• SaaS-embedded agents shipped inside tools the business already uses, like the assistant inside a CRM.
• Workflow agents orchestrating multi-step processes across applications.
• Coding and data agents that write changes, run queries, or move records.
• Autonomous systems that act without a human in the immediate loop.

NIST already wrote the hard requirements for a list like this, in the system component inventory control CM-8. An inventory has to "Accurately reflect the system", include all components, be "at the level of granularity deemed necessary for tracking and reporting", and it must not "include duplicate accounting of components or components assigned to any other system". The discussion adds the mechanism: preventing duplicate accounting "necessitates use of a unique identifier for each component."

That implies two decisions on day one. Every agent gets a stable identifier that survives a rename, which the Agent Access Control Taxonomy calls aact:identity-model/per-agent-identity, and belongs to exactly one system of record. Skip the first and you cannot correlate the registry with your logs. Skip the second and the same agent shows up three times under three team names.

2. Define the Registration Fields

The registry is only as useful as the schema behind it. Each entry needs enough context to answer a governance question without a follow-up investigation.

{
  "agent_id": "ag_01J8ZQ4X2C",
  "name": "ledger-reconciler",
  "version": "4.2.0",
  "owner": "dana.okafor@corp.example",
  "business_unit": "Finance / Controllership",
  "use_case": "Match daily ledger entries to bank statements",
  "platform": "internal-orchestrator",
  "environment": "production",
  "tools": ["erp.read", "bank-feed.read", "ticketing.write"],
  "permissions": ["read:ledger", "create:exception-ticket"],
  "credentials": "vault://agents/ledger-reconciler",
  "acts_on_behalf_of": "finance-ops-service-account",
  "risk_level": "high",
  "status": "active",
  "lifecycle_state": "production",
  "audit_log": "siem://agents/ledger-reconciler",
  "last_attested": "2026-06-01"
}

This agent can read the ledger but only create exception tickets. It never posts financial corrections itself. The schema makes that boundary explicit and reviewable rather than something the owner would describe from memory.

Four of those fields are the ones teams leave out and later wish they hadn't. agent_id is CM-8's unique identifier. version says which build was running when something went wrong. status stops a stale entry from looking current, and regulators agree it belongs: Annex VIII of the EU AI Act requires a status among "on market/in service; no longer available; recalled". last_attested is what makes periodic review possible.

What Working Registries Actually Enforce

Most internal agent registries are a table anyone with access can write to. Two public registries built in the last two years took a different view, and the difference is worth copying.

The official MCP registry requires publishers to prove they control the name they publish under: "Publishers must prove ownership of their namespace. For example to publish to com.example/server, the publisher must prove they own the example.com domain." It verifies package ownership on top of that, explicitly to prevent "impersonation", and restricts which package registries an entry may point at, because "Private registries and alternative mirrors are not allowed." It also keeps status (active, deprecated, deleted), publishedAt, updatedAt and isLatest as registry-managed metadata rather than publisher-supplied. It entered preview in September 2025 and froze its API at v0.1 that October, so treat the shape as stable and the product as young.

A2A took the complementary approach. An agent publishes a card at https://{agent-server-domain}/.well-known/agent-card.json, and the spec names three discovery paths: that well-known URI, "curated registries" where "an intermediary service (the registry) maintains a collection of Agent Cards", and direct configuration. It also defines card signing over JWS, an authenticated extended card for details a public one should not carry, and registry selective disclosure, where registries "return different Agent Cards based on the client's identity and permissions".

Both designs exist because the alternative has a named attack. OWASP's Top 10 for Agentic Applications lists, under identity and privilege abuse, an attacker who "registers a fake 'Admin Helper' agent in an internal Agent2Agent registry with a forged agent card", after which "other agents, trusting the descriptor, route privileged maintenance tasks to it."

Table 1 — Three answers to the same four questions. The third column is what most enterprises have, and the first two show what it is missing.

3. Create an Intake Process

A registry without a front door fills up only with the agents someone happened to remember. Intake is the path teams take to register an agent before it moves into production, and its design decides whether the registry stays complete.

The tension to manage is friction against completeness. Make intake a committee review and engineers ship agents quietly around it. Make it a free-text form and you get entries too vague to govern. We think the resolution is to match effort to risk: a read-only internal helper clears intake in minutes through a self-service form, while an agent that can move money or touch regulated data triggers a deeper review.

The most durable intakes meet teams where they already work. An HR team registering a candidate-screening agent should be able to do it from its usual ticketing system. A platform team should be able to register agents as code, so the entry is part of the deployment rather than an afterthought.

• Capture the baseline fields with minimal ceremony by default.
• Route higher-risk agents to security or compliance review automatically.
• Make registration a prerequisite for a production credential, so the path of least resistance runs through the registry rather than around it.

4. Connect the Registry to Authorization

A registry that's purely informational becomes a wiki nobody trusts. The leap that makes it a control plane is connecting registration to authorization: what an agent is allowed to access and which actions it may perform.

Concretely, the registry becomes a source of truth other systems enforce against. When a sales-operations agent requests a token to update opportunity records, the issuing system checks the registry. Is this agent registered, approved, and scoped for write:opportunities? If the answer is no, the credential is never minted.

That closes the gap between intent and enforcement. Permissions declared at intake stop being documentation and become the boundary the runtime honors. Changes also flow through one place: widening a legal-research agent's access to a new contract repository is a registry change that triggers review, not a silent config edit.

One caveat worth designing for. A registry check at issue time is a point-in-time decision (aact:authorization-model/scope-at-grant), and OWASP names the resulting gap: "Permissions may be validated at the start of a workflow but change or expire before execution. The agent continues with outdated authorization." The mitigation is boring. Keep issued credentials short-lived so a revoked registration expires in minutes, and re-check the registry on issue rather than caching its answer for the life of the process.

Figure 1 — The registry's build pipeline, from intake through the loop that keeps registrations honest.

5. Connect the Registry to Monitoring and Audit Trails

The registry says what an agent is supposed to do. Trust also requires knowing what it actually did. This step links each entry to the evidence of its behavior.

Practically, every record should point to where that agent's activity is logged, so an investigator never has to guess. When a data-analytics agent runs an unexpectedly broad query against a customer table, the entry routes straight to the audit trail showing the statement, the identity it used, and the result. Declared scope and observed behavior sit side by side.

Two requirements belong in the schema rather than a runbook. The first is retention: deployers of high-risk AI systems under the EU AI Act must keep automatically generated logs "at least six months, unless provided otherwise in applicable Union or national law." Whatever your own floor is, record it on the entry, because that is where an auditor starts.

The second is the registry's own audit trail. NIST asks organizations to "Automatically audit account creation, modification, enabling, disabling, and removal actions." A registry that grants production credentials is an account system, so who changed which entry, when, and from what to what is evidence too.

This connection also surfaces drift. If the registry says an IT-operations agent should only restart services in a staging cluster, but monitoring shows calls hitting production endpoints, that gap becomes visible rather than buried in a log nobody reads.

6. Lifecycle Management

Agents get proposed, tested, promoted, and eventually retired, and a registry should model that journey explicitly so different stages can carry different requirements.

Figure 2 — Seven states, and the transition that does the real work: Deprecated to Decommissioned, which has to revoke credentials mechanically rather than by ticket.

• Proposed: an owner and an intent, nothing built.
• Experimental: synthetic or low-risk internal data only.
• Pilot: limited real use, tighter monitoring.
• Approved: cleared for production within its declared scope.
• Production: full scope, continuous oversight.
• Deprecated: access being wound down.
• Decommissioned: credentials revoked, access removed.

Seven states is more than a machine needs, which is fine as long as each distinction earns its keep in review. Compare the MCP registry solving the same problem with three statuses held by the registry rather than the publisher. If all seven of your states are editable by the agent's owner, you have seven labels rather than a lifecycle.

The transitions matter more than the states. Pilot to production is a natural review gate. A move to decommissioned should mechanically trigger credential revocation, and revoking your own copy of a credential is not the same act as revoking the grant at the provider. Both belong in the offboarding path.

7. Periodic Review

Registrations rot. An agent approved a year ago may have accumulated permissions, lost its original owner to a reorg, or quietly stopped being used while keeping live access. The defense is to make entries expire or require attestation rather than persist by default.

NIST's account-management guidance is unusually direct about which accounts to disable, and the list maps onto agents almost word for word: accounts that "Have expired", that "Are no longer associated with a user or individual", that "Are in violation of organizational policy", or that "Have been inactive for" an organization-defined period. An orphaned security-scanning agent with standing access and no accountable owner is the second of those four.

On a recurring cadence, owners confirm three things: the agent is still doing real work rather than holding credentials, its permissions haven't crept beyond the approved use case, and its logs are intact and findable. Record the attestation date on the entry, because that field is how you find the agents nobody will vouch for.

The other half of review is looking for what never registered. NIST's inventory control has an enhancement for it, detecting unauthorized components and then taking one of three actions: "disable network access by such components; isolate the components; notify" a defined role. Reconciling issued credentials and observed API callers against the registry is the agent-shaped version of that scan, and the gap it finds is your shadow estate.

Where Registration Is Already Law

If you want a field list somebody else has argued over, the EU AI Act has one. This is not the general compliance story, which we cover separately. It is narrower and more useful here: a working registry, operated by a regulator, with published contents.

Under Article 49, a provider of a high-risk system listed in Annex III must "register themselves and their system in the EU database" before placing it on the market, and a provider who concludes under Article 6(3) that a system is not high-risk registers that conclusion too. Public-authority deployers register themselves and their use of the system. Article 71 makes the Commission the controller of that database and requires Article 49 registrations to be "accessible and publicly available in a user-friendly manner".

Annex VIII Section A is the part to copy: provider contact details, the system's trade name and identification reference, the intended purpose and conditions of use, a "basic description" of data inputs and operating logic, market status, certificate details, member states of availability, and the instructions for use.

The dates moved, so quote them carefully. The AI Omnibus entered into force on 27 July 2026 and pushed the high-risk obligations back: rules for "systems used in certain high-risk areas", including biometrics, critical infrastructure, education, employment, migration, asylum and border control, now "apply from 2 December 2027", and for "systems integrated into products such as lifts or toys", from 2 August 2028. Anything still citing 2 August 2026 for high-risk obligations is out of date, including plenty of published guidance.

Where Fabriq Fits

The parts of this Agentic Fabriq implements are the mechanical ones. Registering an agent follows a register, scope, activate flow with a one-time secret and an in-console test before it goes anywhere. Access is default-deny across org, team and member, and an agent's effective tool list is the intersection of the acting user's scopes and the agent's own. Every call carries two identities and lands in audit logging you can filter in the dashboard, with export through the API as NDJSON.

What it does not do is run your review. There is no approval workflow in the product, so the risk-tiered intake in step 3 lives in whatever change process you already have. And it cannot revoke a grant upstream: clearing a vault copy removes our access and leaves the provider-side grant in place, so step 6 still ends with a call to Google, Microsoft or Slack.

Frequently Asked Questions

What fields does an agent registry need? At minimum a stable identifier, an owner, a use case, the environment, the tools and permissions granted, where the credential lives, whose authority it acts under, a status, and the date of the last attestation. If you want an externally argued baseline, Annex VIII Section A of the EU AI Act lists what a regulator asks for, including a market status field.

Who should own the agent registry? Whoever owns credential issuance, because that is the wiring that makes registration mandatory. A registry owned by a team that cannot withhold a credential is a documentation project.

How do you stop teams bypassing the registry? Make the registry the only path to a production credential and keep the low-risk path genuinely fast. Everything else is exhortation. Then run the reconciliation in step 7 so bypasses show up as unregistered callers rather than as a clean report.

How do you prevent a forged or impersonating entry? Require proof for the name. The MCP registry's model is that a publisher must prove they own the domain behind their namespace, and A2A's is that a card can be signed and served from the agent's own domain. OWASP's forged "Admin Helper" scenario is what happens with neither.

How long should we keep the logs a registry entry points at? Longer than you think, and write the number down per entry. Deployers of EU high-risk systems must keep automatically generated logs for "at least six months, unless provided otherwise in applicable Union or national law", and sector rules run considerably longer.

Do we have to register agents with a regulator? Only in specific cases. Article 49 of the EU AI Act requires registration in the EU database for providers of Annex III high-risk systems and for public-authority deployers, with those obligations applying from 2 December 2027 for the Annex III areas and 2 August 2028 for systems embedded in regulated products. Internal agents that are not high-risk are governed by your own registry, not the EU's.

Conclusion

A registry changes what an enterprise can say about its agents. Instead of guessing how many exist, it can name which ones are trusted, why, and on whose authority, because every step from intake through review fed the same record.

The seven steps by themselves are not the hard part. A schema, a form, a set of labels. What makes a registry real is wiring authorization to read from it. Skip that one connection and the other six are paperwork with a nicer schema.

A pragmatic rollout follows that logic. Start with the schema and a light intake form so coverage grows. Wire authorization next, because that turns a list into a control plane and gives teams a reason to keep entries accurate. Lifecycle states, attestation and reconciliation follow. Throughout, resist gold-plating: every field you require should answer a question someone will actually ask.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the identity-model and authorization-model dimensions: a registered per-agent identity that can be revoked on its own, and the difference between deciding at grant time and deciding per action.
• NIST SP 800-53 Rev. 5 — CM-8 system component inventory, including the no-duplicate-accounting requirement and the unique-identifier discussion; CM-8(3) unauthorized component detection and its three response actions; AC-2(3) conditions for disabling accounts and AC-2(4) automated audit of account changes.
• NIST AI Risk Management Framework, AI 100-1 — GOVERN 1.6, mechanisms to inventory AI systems "resourced according to organizational risk priorities", and GOVERN 1.7 on decommissioning.
• MCP official registry: server.json requirements — namespace authentication by proof of domain ownership, package ownership verification against impersonation, restricted registry base URLs, and the registry-managed status, publishedAt, updatedAt and isLatest metadata.
• MCP registry README — preview launch September 2025 and the v0.1 API freeze of October 2025.
• A2A: Agent discovery — the /.well-known/agent-card.json path, the three discovery mechanisms, and registry selective disclosure.
• A2A protocol specification — Agent Card fields, authenticated extended cards, and card signing over JWS.
• OWASP Top 10 for Agentic Applications 2026 — published December 2025. ASI03, Identity and Privilege Abuse, supplies the forged "Admin Helper" registry scenario and the workflow authorization drift description. Text read from the project's own source repository at GenAI-Security-Project/translations.
• EU AI Act Article 49: Registration — who registers what, and when, before market placement or putting into service.
• EU AI Act Article 71: EU database for high-risk AI systems — the Commission as controller and the public availability of Article 49 registrations.
• EU AI Act Annex VIII — the provider field list in Section A, including market status, and the deployer fields in Section C.
• EU AI Act Article 26: Obligations of deployers — assigning human oversight, and log retention of at least six months.
• European Commission: Regulatory framework for AI — the AI Omnibus in force 27 July 2026, high-risk areas applying from 2 December 2027, and product-embedded systems from 2 August 2028.