The agent registry is becoming the artefact that “know your agent” gets checked against: not a list of models, but a record of which agent exists, who owns it, what it may reach — and whether that is still true today.
What happened
On 30 October 2026 the AWS Partner Network blog published a post by John Brunot of AWS and Suresh Sridharan of Saviynt describing how Amazon Bedrock AgentCore and Saviynt Zuma are combined to govern agent identity across its lifecycle.
The problem statement is the KYA problem in vendor language: “Most organizations, however, manage agents as application components rather than as governed identities. As a result, security teams cannot answer basic questions: which agents exist, who owns them, what they can access, and whether that access remains appropriate.”
And the artefact it points to: “without a registry that records each agent’s owner, purpose, and scope at creation, organizations cannot reliably run access reviews or produce an audit trail.”
The architecture splits in two. The runtime side is AgentCore: AgentCore Runtime for isolated execution, AgentCore Identity for brokering credentials through corporate identity providers, AgentCore Gateway for exposing APIs, Lambda functions and MCP servers as tools, deterministic policy (written in Cedar or natural language), AWS Agent Registry as a catalogue of agents and tools, and Observability for per-session traces. The governance side is Zuma: discovery that captures each agent’s model, connected MCP servers and tools, owner, permissions and lifecycle state; runtime evaluation; and ownership rules, access-certification campaigns and evidence from registration through deprovisioning.
The runtime check is the part worth reading closely. Before an agent acts, an identity-aware authorisation service confirms that the agent is registered, that its owner is current, that its access has been certified, and that the request matches its approved purpose — and distinguishes whether the agent is acting independently, on behalf of a user, or through delegation.
On regulation, the post argues that the EU AI Act, DORA and NIS2 “impose risk-management, access-control, and logging duties… These duties apply to autonomous systems by the function they perform. An agent registry supports the inventory, accountability, and audit expectations these frameworks set.” It adds its own caveat: “Consult your legal and compliance teams to determine which requirements apply to your workloads.”
Why it matters for KYA
The registry is the substrate. KYA asks who an agent is, who is accountable for it and what it may do. A registry is where those three answers live as data rather than as a paragraph in a design document. The post’s insistence on capturing owner, purpose and scope at creation — via a connector or directly from a CI/CD pipeline — is the difference between an inventory and an archaeology project.
Design-time permission is not request-time authority. The sharpest line in the post: “coarse-grained permissions describe what an agent can do at design time, not what it should do in a specific request context.” That is the failure mode KYA keeps pointing at. An agent holding read access to a CRM may summarise an opportunity and, on the same grant, export the table. The vendor’s answer is a second check that asks whether the identity making this call is still owned, still certified, still within purpose.
Delegation is treated as a distinct state. Independent, on-behalf-of, delegated: three modes with different risk, decided at authorisation time rather than assumed. That matches the standards work — scope attenuation down a delegation chain — and it is the part most enterprise agent deployments skip.
Evidence beats logs. Audit evidence “spanning the full identity lifecycle from registration through deprovisioning” is a different claim from “we log tool calls”. A log tells you what happened; a lifecycle record lets a reviewer ask whether the agent should have existed at all, and who signed off.
Caveats
This is vendor architecture guidance, not a standard and not a regulator’s requirement. The mapping to the EU AI Act, DORA and NIS2 is the authors’ reading of duties that apply “by the function performed”, and the post itself defers to legal review — no supervisory authority has endorsed an agent registry as a compliance artefact. There are no customer deployments, figures or independent tests in the post. And a registry operated by one platform is a commercial catalogue, not a neutral cross-organisational one: who can vouch for an entry when the agent, its owner and the relying party sit in three different companies remains an open KYA question.
Sources
- AWS Partner Network Blog, “Governing AI agent identity with Amazon Bedrock AgentCore and Saviynt Zuma”, 30 October 2026 — aws.amazon.com
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.