AGNTCY Explained: Agent Directory, OASF, SLIM and Agent Identity

AGNTCY is an open source project, hosted by the Linux Foundation since 29 July 2025, that builds shared infrastructure for AI agents to find each other, prove who they are and exchange messages. Its main parts are the Open Agentic Schema Framework (OASF) for describing agents, the Agent Directory for publishing and discovering those descriptions, SLIM for encrypted agent messaging, and an Identity component built on verifiable credentials.

That is the short answer. The longer one matters to anyone who lets an agent pick a collaborator, a tool or an MCP server from a listing, because a directory entry is a pointer to code you are about to trust. This guide goes one level deeper than our posts on how A2A and MCP work on the wire, agent identity and short-lived credentials and AI agent tool calling security. Every date, command and design rule below comes from AGNTCY's own site, documentation and GitHub repositories, the Linux Foundation's announcements, the IETF drafts the project has filed, the A2A specification and modelcontextprotocol.io. Where the documentation leaves a question open, we say so.

Key takeaways

• The Linux Foundation welcomed AGNTCY on 29 July 2025. The project had first been open sourced in March 2025, and more than 65 companies supported it at the time of the move.
• OASF is a JSON data model for an "agent record": name, version, authors, skills, domains, modules and locators, with skills and domains drawn from a published taxonomy.
• The Agent Directory stores records in an OCI registry by content identifier (CID) and announces them over a distributed hash table. Records are unsigned by default.
• Signing is optional (keyless OIDC through Sigstore, a self-managed key or a KMS key). A bare dirctl verify accepts any valid signature, so pin the expected key or OIDC issuer and subject.
• A record's name is not verified. Ownership is proved with signed claims checked against DNS, a JWKS file, a DID document, a SPIFFE trust bundle or a certificate.
• SLIM separates a routing data plane from a session layer. End to end encryption uses Messaging Layer Security (MLS, RFC 9420), so routing nodes never see plaintext. Identity binding between names and identities defaults to warn mode, not enforce.
• AGNTCY sits alongside A2A and MCP rather than replacing them: the directory can index A2A Agent Cards and MCP servers, and SLIM can carry A2A and MCP traffic.
• The main risks are familiar supply chain ones in a new place: poisoned or impersonated entries, prompt injection in descriptions, and vulnerable dependencies in the code records point to.

What is AGNTCY?

AGNTCY describes itself on its home page as an open source stack that lets AI agents "collaborate across vendors and frameworks" through four capabilities: discovery, identity, messaging and observability. The documentation home calls it "an open source collective" building the components that let agents discover each other, verify capabilities, communicate securely and collaborate across organizational boundaries. The project uses the phrase "Internet of Agents" for the network it is aiming at.

The components listed on agntcy.org and docs.agntcy.org today are:

The home page also lists AgentBridge, which it describes as connecting coding agents and other command line tools over A2A so they can hand off context and delegate tasks. Client libraries cover Go, Python, .NET, Java, Kotlin and React Native, according to the same page.

Who launched it, and when?

The Linux Foundation's press release, datelined San Francisco on 29 July 2025, says AGNTCY was "initially open sourced" in March 2025 with collaboration from two AI tooling companies. The GitHub API reports that the agntcy organization was created on 30 January 2025, which fits a project built in private for a few weeks before it went public. We are not naming the founding or member companies here; the Linux Foundation release lists them, along with five "formative members" that joined when the project moved under Linux Foundation governance.

When did it move to the Linux Foundation?

On 29 July 2025. The Linux Foundation release says it "today welcomed" AGNTCY and that the project would be governed under the Linux Foundation from then on. The agntcy.org footer now reads "Copyright AGNTCY a Series of LF Projects, LLC", which is the standard legal wrapper the Linux Foundation uses for hosted projects, and the site lists a Technical Steering Committee.

The Linux Foundation had launched the Agent2Agent (A2A) project five weeks earlier, on 23 June 2025, and the AGNTCY release mentions A2A as "recently" contributed. Later, on 9 December 2025, the Linux Foundation announced the Agentic AI Foundation for MCP and related projects. AGNTCY remains its own LF project.

Timeline

Both IETF documents are individual Internet Drafts with Informational intended status. An Internet Draft is a work in progress, not a standard, and the Datatracker pages say these two expire in January 2027 unless they are revised.

What is the Open Agentic Schema Framework (OASF)?

OASF is a schema system for describing AI agents and the things around them. The OASF README calls it "a standardized schema system for defining and managing AI agent capabilities, interactions, and metadata", built on attribute based taxonomies. It ships as a schema plus a schema server that can browse the schema and validate records, and it can be extended with private schema extensions that keep validation working.

The project is open about its lineage. OASF is "highly inspired" by the Open Cybersecurity Schema Framework (OCSF) in both data modelling and implementation, and the OASF schema server is a derivative of the OCSF schema server. If you have worked with OCSF event classes and categories, the shape of OASF will feel familiar: categories, classes with numeric IDs, and objects that compose into a record.

What does an OASF record contain?

The central object is the record. The "Creating an Agent Record" guide lists the fields a publisher fills in:

How does OASF describe skills, inputs and outputs?

Skills are hierarchical names with numeric class IDs. The docs give natural_language_processing/natural_language_generation/text_completion as a skill name and technology/network_operations as a domain. The published example record for a tourist scheduling coordinator lists three skills under agent_orchestration, such as task_decomposition with ID 1001 and multi_agent_planning with ID 1003, and one domain, hospitality_and_tourism/tourism_management with ID 1505.

OASF does not carry a full input and output schema for every skill in the record itself. That detail lives in modules. The modules catalog is where a record describes how an agent is reached and run: for example an A2A module that stores the agent's Agent Card, or an MCP integration module that describes an MCP server and, according to the directory's trust model page, can carry an agent skills bundle. The translation service in the OASF SDK shows the practical effect. It can turn an OASF record into an A2A card structure (name, description, URL, capabilities, default input and output modes, skills) and into an MCP client configuration whose server entries hold a command, args and env.

That last point deserves a pause. A record that converts into an MCP configuration converts into a command line your client will execute. The schema is descriptive, but downstream tools turn it into something that runs.

How is OASF versioned?

The README states an immutability policy: once a schema version is released, only non-breaking fixes such as documentation updates or minor corrections go into it, and any structural change waits for the next version. The latest release on GitHub at the time of writing is OASF v1.1.0, published on 10 July 2026, while the docs' own examples still use schema_version 1.0.0. Pinning schema_version in your records means a validator checks you against a fixed target, which is what you want for reproducible validation.

Can other formats carry OASF skills?

Yes. The OASF README says formats other than OASF records, "such as A2A Agent Cards and AI Catalog entries", can carry the same skills and domains through the discovery extension. This is how AGNTCY tries to avoid becoming one more competing card format: an A2A Agent Card can be annotated with OASF skills and still be an A2A Agent Card.

How does the Agent Directory work?

The Agent Directory Service, usually shortened to ADS and shipped as the dir repository with a dirctl command line tool, is a distributed registry for OASF records. Its overview page describes "distributed directories that interconnect through a content-routing protocol" mapping agent skills to record identifiers and to the directory servers that hold those records.

Storage: OCI registries and content identifiers

Each record is stored in an OCI registry, the same kind of registry that holds container images. The local daemon runs an OCI registry on port 5555, and the Docker Compose deployment uses Zot, an open source OCI registry, alongside PostgreSQL. A record is addressed by a Content IDentifier (CID), a hash digest that the docs describe as globally unique, content addressable, collision resistant and immutable. Change one byte of the record and you get a different CID.

Signatures, public keys, scan reports and identity claims are stored next to the record as OCI referrer artifacts. A referrer is an artifact that points at a subject artifact, which is how the OCI ecosystem attaches signatures and SBOMs to images. ADS reuses that machinery for agent records.

Routing: announcing skills over a DHT

Publishing has two steps. dirctl push stores the record and returns its CID. dirctl routing publish announces it to the network. The overview page explains that routing is driven by a subset of attributes (skills, domains, modules and locators) that are announced as labels into a distributed hash table (DHT). Peers looking for a skill query the DHT, learn which directory nodes hold matching records, and pull them.

The quickstart draws a clear line between local and network search. dirctl search queries the local store. dirctl routing list shows what this peer has announced. dirctl routing search queries cached network announcements and "deliberately excludes local records", so it returns nothing on a single node.

Federation and trust domains

Directory nodes authenticate each other with SPIFFE identities issued by SPIRE. The trust model page says SPIRE gives each component a SPIFFE ID, enables mutual TLS between services, and lets separate organizations federate by exchanging trust bundles. Authorization is currently static and based on SPIFFE IDs: your own trust domain may call every method, while external trust domains are allowed a short list that includes Store.Pull, Store.Lookup, Store.PullReferrer and Sync.RequestRegistryCredentials. The docs say dynamic, attribute based policies are planned.

The documentation also points to a public directory network that new nodes can federate with. Federation means records announced elsewhere become discoverable from your node. It does not mean they were vetted by anyone you know.

Signing records

The quickstart is blunt: "Records are unsigned by default." Signing is something a publisher chooses to do. The trust model page lists four methods:

When a record is signed, the signature is attached as a Cosign compatible OCI artifact. Server side, the directory asks the registry's trust extension whether each signature is valid and whether it matches an uploaded public key, and records IsSigned and IsTrusted flags. Search can filter on those flags with the trusted flag.

Verifying a signature, and the catch

dirctl verify <cid> fetches signatures from the directory and checks them. The CLI reference describes the bare form as "Verify any valid signature on the record". That is the catch. With keyless signing, anyone with an OIDC identity can produce a valid signature. A record signed by a stranger's throwaway account verifies just as well as one signed by the vendor you meant to trust.

To make verification mean something, pin who you expect:

• The key flag with the publisher's public key, when they sign with a managed key.
• The oidc-issuer and oidc-subject flags, both of which accept regular expressions, when they sign keylessly. Pin the exact issuer and the exact subject, such as a specific CI workflow identity, and avoid loose patterns.

The reference also notes that settings which weaken verification (skipping the transparency log, the timestamp authority or the certificate timestamp check, a custom trusted root, or a non default TUF mirror) print a warning when they come from a config context or environment variable rather than a flag. Treat those warnings as a failed check in automation. And the from-server flag uses the server's cached result; for a decision that gates execution, verify on the client.

Names are labels; claims carry ownership

Two documentation pages repeat the same sentence: a record's name "is a label chosen by the publisher and is not verified". Anyone can push a record named example.com/agents/payments. What links a record to an organization is a pair of signed claims.

The record declares a subject in the agntcy.dir/identity annotation (the agent's own identity) or the agntcy.dir/owner annotation (the entity that owns it). Because the annotation is part of the record, it is covered by the CID and cannot change later. The publisher then signs a claim for that subject with a key the subject publishes and attaches it as a referrer, using dirctl identity claim.

Supported subjects include a DNS domain (key in a DNS TXT record), an HTTPS host (/.well-known/jwks.json), a DID document, a SPIFFE trust bundle, or a certificate attested by an ANS transparency log. The reconciler's identity task re-checks every claim on a schedule, so a rotated key or revoked bundle is caught on the next run. A freshly pushed claim has "no result" until that task runs. Clients read the outcome with dirctl identity status or filter search with the identity-verified flag, the owner-verified flag or the verified flag.

Validation, content policy and scanning

ADS can evaluate records against policies written in OPA (Rego) or CEL. The content policy page describes a strict model: when enforcement is on, a record is returned only if it has a passing verdict under the current version of every enforced policy, and records never evaluated are withheld. A read of a withheld record by CID gets PermissionDenied without saying why. The page warns that registry credentials read records straight from the registry and bypass these checks, so authorization must be on and registry credentials limited to peer nodes.

The reconciler can also run optional external scanners: behavioural analysis of the source repository named in a record's source_code locator, analysis of an attached skill bundle, and a check of an A2A Agent Card. Scanners run only if their binaries are installed; a record whose applicable scanners were all skipped is not matched by the safe flag. Results expire after a configurable TTL that defaults to seven days. A clean scan result is one more input, not a guarantee, and a scanner that clones the source at scan time is looking at whatever that repository contained then.

What is SLIM, and what does it add for agent messaging?

SLIM stands for Secure Low-Latency Interactive Messaging. The SLIM README calls it a communication framework providing "the secure, scalable transport layer" for agent protocols such as A2A and MCP. It is written in Rust, with bindings for Python, Go, .NET, JavaScript and TypeScript, Java and Kotlin, and integrations for A2A, MCP and OpenTelemetry.

Architecture: data plane, session layer, control plane

SLIM's architecture page describes three parts:

• Data plane. Routing nodes forward messages based on hierarchical names. They do not inspect application content, do not join application sessions and, per the docs, "never see plaintext message content". Connections between clients and nodes, and between nodes, can use TLS or mutual TLS.
• Session layer. Lives inside each application. It handles session setup, reliable delivery, group membership and end to end encryption with the Messaging Layer Security protocol, MLS, defined in RFC 9420. Only the communicating endpoints hold session keys.
• Control plane. A separate controller that configures routing nodes and route tables through slimctl and a gRPC API. Messages never pass through it, and the data plane can run without it.

The useful property for security teams is the split between hop by hop and end to end protection. TLS protects each link. MLS protects the content from one agent to another across any number of routing hops, including hops run by someone else.

Names and delivery modes

Every SLIM endpoint has a four part name: organization/namespace/service/id. The first three parts are chosen by the application. The last is the XXH3-128 hash of the application's identity. Addressing only the first three parts gives anycast delivery to any instance of a service; including the ID gives unicast to a specific instance. Channels for group messaging use the same structure, and their IDs derive from the moderator's identity and the channel name.

The naming page includes a warning worth quoting in substance: XXH3 is not a cryptographic hash, so a name ID helps routing but "doesn't prove who a peer is". If you need to know who is on the other end, pin the peer's identity, not its name.

How SLIM authenticates applications

SLIM treats transport security and application identity as separate concerns. The application identity travels with every message and is checked by the receiving session. Three credential methods are documented:

The shared secret section is unusually candid. Anyone holding the secret can sign as any identity that shares it, there is "no per-application isolation and no non-repudiation", and one leak compromises every identity using it.

Identity binding, and why the default matters

SLIM checks that a sender's name ID matches the identity it verified, for control messages, invites, membership updates and, with MLS, data messages. This is called identity binding, and it is controlled by the SLIM_IDENTITY_BINDING environment variable. The values are warn (the default, which logs a mismatch), enforce (which drops the message) and off.

The docs also note that without MLS, data messages are not authenticated end to end. Put together, the secure configuration is MLS on, per application credentials (JWT or SPIRE), identity binding set to enforce, and pinned sessions (create_session_pinned or invite_participant_pinned) wherever you know which peer you expect. The docs advise checking logs for mismatches before switching to enforce, because some identity providers and channel setups will trip it.

Groups and moderators

A SLIM group is a set of applications on a shared channel. Each group has a moderator, the only participant allowed to invite and remove members. Membership changes are strongly consistent: the moderator sends an MLS commit to the group, every member acknowledges, and only then does the new member receive a Welcome. The moderator can be an agent or a Channel Manager service operated with slimctl channel-manager. That gives a clear trust boundary, and a clear target: whoever controls the moderator controls who can read the group.

How does AGNTCY relate to A2A and MCP?

They are designed as layers, with some overlap at the edges.

A2A (now at version 1.0.0 of its specification) defines how one agent sends tasks and messages to another, and how an agent describes itself in an Agent Card. The specification places the card at https://{server_domain}/.well-known/agent-card.json and defines an optional AgentCardSignature: a JSON Web Signature (RFC 7515) computed over the card after canonicalization with the JSON Canonicalization Scheme (RFC 8785). Discovery in A2A is largely "know the domain, fetch the card", with an authenticated extended card for details you only show to known clients.

MCP defines how an AI application connects to tools, resources and prompts exposed by servers. For discovery, modelcontextprotocol.io describes the MCP Registry, currently in preview, as "the official centralized metadata repository for publicly accessible MCP servers". It uses reverse DNS style names tied to verified GitHub accounts or domains, holds metadata that points to packages on npm, PyPI, Docker Hub and similar registries, and delegates security scanning to those package registries and to downstream aggregators.

AGNTCY adds three things that neither protocol defines on its own:

1. A common, taxonomy based description (OASF) that can annotate both A2A cards and MCP server listings.
2. A federated directory that can index A2A agents and MCP servers side by side. The dirctl import command can import records from an MCP registry URL, optionally signing them on the way in.
3. A transport (SLIM) that can carry A2A and MCP sessions with group messaging and MLS encryption.

The Linux Foundation release states this relationship directly: AGNTCY makes "A2A agents and MCP servers discoverable through AGNTCY directories" and supports message transport over SLIM.

The overlap is discovery metadata: an A2A Agent Card, an MCP Registry entry and an OASF record can describe the same agent three ways, and AGNTCY's answer is translation plus the discovery extension, not replacement.

What identity and trust features does AGNTCY document?

Identity shows up in three places, and it helps to keep them apart.

1. The Identity component: IDs, badges and verifiable credentials

The agntcy/identity repository describes a way to give agents, MCP servers and multi-agent systems a universally unique identifier backed by verifiable credentials (VCs). The specification site lists core properties: no central authority is needed to assign identities, each entity has a universally unique identifier, and each is backed by a VC that can prove its ID and provenance.

Identities can be "brought" from existing conventions (IDs issued by an enterprise identity provider, or A2A Agent Cards) or assigned under standards such as W3C Decentralized Identifiers (DIDs). Each ID links to a ResolverMetadata object used for automated verification and to one or more Agent Badges. A badge is a VC carrying the agent's ID, a schema definition such as an OASF record, and metadata for authentication. The README's reasoning for multiple badges is least privilege: task specific badges let an agent reach different systems without one over privileged credential.

The repository ships an Issuer CLI (create identities, register them, issue and verify badges, and store signing keys locally or in a vault) and a Node Backend that stores organization and sub-organization IDs, public keys, badges, resolver metadata and VCs.

2. Directory identity and ownership claims

Covered above: signed claims that tie a record to a DNS name, HTTPS host, DID, SPIFFE trust bundle or certificate, re-verified on a schedule.

3. SLIM application identity

Covered above: shared secret, JWT or SPIFFE identity per application, with identity binding and pinned sessions.

What gaps remain?

Reading the documentation end to end, these are the places where the trust story depends on you rather than the project:

• Defaults are permissive. Records are unsigned by default, bare verification accepts any signer, SLIM identity binding defaults to warn, and the shared secret mode offers no per application isolation. Each is documented, and each is a setting someone has to change.
• Names are not identities. Both ADS and SLIM say so explicitly. Tools and people will still read names as identities unless the interface makes the difference obvious.
• A verified owner is not a vetted agent. An ownership claim proves a key holder for dns:example.com signed the claim. It says nothing about whether the code behind the locator is safe, current or the code that was reviewed.
• Metadata describes; it does not constrain. Skills and domains are self declared. Nothing in OASF stops an agent that claims "summarization" from also making network calls.
• Revocation is eventual. Claims are re-checked on the reconciler's interval, and scan results on a TTL. Between runs, stale results stand.
• Federation multiplies publishers. Joining a public network makes many strangers' records discoverable. Content policies and pinned verification are your filter.
• Several pieces are young. The IETF documents are individual drafts. Release cadence is fast (SLIM shipped v3.4.6 across many crates on a single day in October 2026). Expect behaviour and flags to keep changing, and pin versions.

What are the risks?

The threats here are not exotic. They are package registry and identity problems, moved into a space where the "package" may be an autonomous program with tools.

Poisoned directory entries

A directory entry has locators: a source repository, a container image, an MCP server package. If an attacker controls what a locator resolves to, they control what runs. That can happen through a malicious record, a legitimate record whose locator points at a mutable tag such as latest, or a source repository that changes after review. CIDs make the record immutable, but they do not make the thing a locator points to immutable unless the locator itself is pinned by digest.

Impersonated agents

Because names are unverified, the simplest impersonation is a record with a convincing name and no claims. A more careful one signs the record with keyless OIDC under an unrelated identity, which passes a bare dirctl verify. In SLIM, a peer can subscribe to a name; only identity binding in enforce mode, MLS and pinned sessions stop a member from sending under another member's name.

Schema level prompt injection

OASF description fields, A2A card skill descriptions and MCP tool descriptions are written by publishers and read by models. When an orchestrating agent searches a directory and feeds record text into its context to choose a collaborator, that text becomes model input. The MCP tools specification makes the same point for its own metadata: clients should treat tool annotations as untrusted unless they come from trusted servers, and there should be a human in the loop able to deny tool invocations. Apply the same rule to directory records. Render them as data, keep them out of system prompts, and never let a description alone authorize an action.

Confused deputy and token handling

MCP's security best practices page lists confused deputy problems, token passthrough, server side request forgery, session hijacking and local MCP server compromise. These carry over when MCP servers are discovered through a directory and launched from a translated configuration. A record that becomes an MCP configuration with command, args and env is exactly the "local MCP server compromise" scenario if nobody checks the command.

Supply chain risk in agent components

Every agent, MCP server and SLIM binding has dependencies. The Directory, SLIM and Identity repositories themselves pull Go modules, Rust crates, Python packages and container base images. An agent described perfectly in OASF can still ship a vulnerable HTTP library. Directory metadata does not include a vulnerability status for the code behind a locator, so that check stays with you.

Risk to control map

How do AGNTCY, A2A Agent Cards, the MCP Registry and an OpenAPI catalogue compare?

A practical reading: the A2A card and the MCP Registry tie trust to a domain or namespace you already know. AGNTCY adds a discovery network where you may not know the publisher, and compensates with signatures and claims you must choose to enforce. An OpenAPI catalogue is the baseline most enterprises already have, and its lack of agent semantics is exactly the gap these projects are filling.

Step by step: run a local Agent Directory, publish, discover and verify

This walkthrough follows the official quickstart and CLI reference for Directory v1.8.0. It runs on one machine, publishes a test record, signs it, and verifies it with the signer pinned. Nothing here deletes data, but the daemon keeps state under ~/.agntcy/dir/, so check that path before you clean up.

Step 1: install dirctl

With Homebrew, the docs use a tap from the project's repository:

brew tap agntcy/dir https://github.com/agntcy/dir
brew trust agntcy/dir
brew install dirctl
dirctl --help

Or download a pinned release binary. The v1.8.0 release lists platform binaries alongside a dirctl-v1.8.0.intoto.jsonl provenance file. Record the hash and check the provenance before the binary goes on your path. The release page does not say which tool generated that file, so confirm in the project's release workflow that it is SLSA provenance before relying on the verifier step below:

VERSION=v1.8.0
curl -LO "https://github.com/agntcy/dir/releases/download/${VERSION}/dirctl-linux-amd64"
curl -LO "https://github.com/agntcy/dir/releases/download/${VERSION}/dirctl-${VERSION}.intoto.jsonl"
shasum -a 256 dirctl-linux-amd64   # record this in your install notes
# Check the provenance with a SLSA verifier, pinned to the source repository and tag
slsa-verifier verify-artifact dirctl-linux-amd64 \
  --provenance-path "dirctl-${VERSION}.intoto.jsonl" \
  --source-uri github.com/agntcy/dir \
  --source-tag "${VERSION}"
chmod +x dirctl-linux-amd64
sudo mv dirctl-linux-amd64 /usr/local/bin/dirctl

A container image is also published at ghcr.io/agntcy/dir-ctl. Use a version tag such as v1.8.0 and, for automation, the image digest.

Step 2: initialise and start a local node

dirctl init          # provisions the local OASF taxonomy extractor; pass --yes in CI
dirctl daemon start
dirctl daemon status

The quickstart notes that dirctl init downloads a model of about 89 MB plus the taxonomy for local record enrichment and natural language search. The daemon exposes an HTTP API and dashboard on localhost:8889, the gRPC directory API on localhost:8888, a DHT API on localhost:8999 and an OCI registry on localhost:5555. Keep those on localhost; none of them should face the internet in a test setup.

Step 3: write and validate an OASF record

cat > record.json <<'EOF'
{
  "name": "example.com/agents/release-notes-summarizer",
  "version": "v0.1.0",
  "description": "Summarizes release notes for internal changelogs.",
  "schema_version": "1.0.0",
  "authors": ["Platform Team <platform@example.com>"],
  "created_at": "2026-10-24T09:00:00Z",
  "annotations": {
    "agntcy.dir/owner": "dns:example.com"
  },
  "skills": [
    {
      "id": 10202,
      "name": "natural_language_processing/natural_language_generation/summarization"
    }
  ],
  "locators": [
    {
      "type": "source_code",
      "urls": ["https://git.example.com/platform/release-notes-summarizer"]
    }
  ]
}
EOF

# OASF_SCHEMA_URL is the hosted OASF schema server linked from docs.agntcy.org, or your own
dirctl validate record.json --url "$OASF_SCHEMA_URL"

The skill ID 10202 and name come from the directory's own example record. The dirctl validate command checks a record against the OASF schema through a schema server URL. Use the hosted schema server the OASF docs link to, or run your own with the OASF server guide, which you will need anyway if you use private schema extensions. Note the agntcy.dir/owner annotation: it is how you will later attach an ownership claim.

Step 4: push and announce

CID=$(dirctl push record.json --output raw)
echo "Stored: $CID"
dirctl routing publish "$CID"

Write the CID down. It is the immutable identity of exactly these bytes. Any change, even to the description, produces a new CID.

Step 5: sign the record

Keyless OIDC signing opens a browser:

dirctl sign "$CID"

In CI, the documented options are an OIDC token from the environment or a key:

# Key based signing; the password is read from stdin, not the command line
printf '%s' "$KEY_PASSWORD" | dirctl sign "$CID" --key cosign.key --password-stdin

For ownership, add a claim for the subject the record declares. The claim is signed with a key whose public half dns:example.com publishes (in a DNS TXT record for a DNS subject). The CLI reference shows this form:

dirctl identity claim --record "$CID" --role owner --key owner.key

The claim stays unverified until the reconciler's identity task runs.

Step 6: discover it

dirctl search --skill "*summarization*"
dirctl routing list --skill "natural_language_processing"
dirctl pull "$CID" --output json

On a single node, dirctl routing search returns nothing because network search excludes local records. In a federation it is the command that finds records announced by other peers.

Step 7: verify with the signer pinned

This is the step most guides skip. A bare dirctl verify "$CID" passes for any valid signature. Pin the identity you expect instead:

# Keyless: pin the exact OIDC issuer and subject you trust
dirctl verify "$CID" \
  --oidc-issuer '^https://token\.actions\.githubusercontent\.com$' \
  --oidc-subject '^https://github\.com/example-org/agents/\.github/workflows/publish\.yml@refs/heads/main$'

# Key based: pin the publisher's public key
dirctl verify "$CID" --key ./publisher-cosign.pub

# Ownership claim status
dirctl identity status "$CID"

# Pull the signature and public key referrers for your records
dirctl pull "$CID" --signature --public-key

Anchor both regular expressions with ^ and $. An unanchored pattern such as example-org would match any subject containing that string. Do not skip the transparency log check in production; that check is what makes keyless signatures auditable.

Step 8: make discovery refuse what verification rejects

dirctl search --skill "*summarization*" --trusted --verified

On a shared node, back this with a content policy so unsigned records are never served. A CEL policy can be as small as a single expression in the server's policy.evaluations block, and the content policy page explains how to enforce it and audit what was excluded.

Step 9: check the code behind the locator

The record is verified. The code is not. Clone the repository at a pinned commit, or pull the image by digest, and scan it before any agent runs it. The "Where Safeguard fits" section after the FAQ covers that part.

Step 10: stop the node

dirctl daemon stop
# State lives here; confirm the path before removing anything
ls ~/.agntcy/dir/

Only delete that directory if you are sure it holds nothing but this test node.

Common mistakes

• Trusting the name. example.com/agents/x in a record is a string the publisher typed. Check owner claims, not names.
• Running dirctl verify with no flags. It accepts any valid signature. Always pin a public key, or an anchored OIDC issuer and subject.
• Ignoring weakened verification warnings. A context that sets ignore_tlog will print a warning on stderr; in CI, fail on it.
• Pointing locators at mutable tags. A signed record with image:latest signs a moving target. Use digests and commit SHAs.
• Leaving SLIM identity binding at warn. It logs impersonation attempts and lets them through. Move to enforce once logs are clean.
• Using a shared secret in production SLIM. Any holder can sign as any other. Use JWT or SPIRE.
• Treating the safe flag as a security review. It means at least one optional scanner ran and found nothing at that time. It is one signal.
• Forgetting the directory's own supply chain. dirctl, the apiserver image, SLIM bindings and the Identity node are software with dependencies. Pin and scan them like anything else.

FAQ

What is AGNTCY?

AGNTCY is an open source project under the Linux Foundation that builds infrastructure for AI agents to discover each other, prove their identity, exchange messages and be observed. Its main components are OASF, the Agent Directory, SLIM and Identity.

When was AGNTCY launched, and who owns it now?

The Linux Foundation says it was first open sourced in March 2025, and it has been hosted by the Linux Foundation as AGNTCY a Series of LF Projects, LLC since 29 July 2025.

What does OASF stand for?

Open Agentic Schema Framework. It is a schema for agent records, with skills, domains and modules drawn from a published taxonomy, modelled on the Open Cybersecurity Schema Framework.

Is AGNTCY a replacement for A2A or MCP?

No. AGNTCY's documentation and the Linux Foundation describe it as interoperable with both. The directory can index A2A agents and MCP servers, OASF records can be translated into A2A cards and MCP client configurations, and SLIM can carry A2A and MCP traffic.

Are Agent Directory records signed?

Not by default. Publishers can sign with keyless OIDC through Sigstore, a self-managed key or a cloud key management key. Consumers must verify with the expected signer pinned.

How does SLIM encrypt messages?

Routing links can use TLS or mutual TLS. End to end, SLIM's session layer uses MLS (RFC 9420), so intermediate routing nodes never see plaintext.

What is the difference between an A2A Agent Card and an OASF record?

An Agent Card describes one A2A agent's endpoint, capabilities, skills and authentication, and is usually served from the agent's own domain with an optional JWS signature. An OASF record is a taxonomy based description stored in a directory by CID, can describe agents and MCP servers, and can embed an Agent Card in a module.

Is the Agent Directory an IETF standard?

Not yet. draft-mp-agntcy-ads-02 is an individual Internet Draft with Informational intended status, as is the SLIM draft. Drafts can change or expire.

Can I run the Agent Directory privately?

Yes. The built-in daemon runs a full node locally, and the project ships Docker Compose and Helm deployments. Federation with other nodes is optional.

Where Safeguard fits

The fit is real but indirect, so here it is plainly. Safeguard does not run an agent directory, does not verify OASF signatures or identity claims, and does not inspect SLIM traffic. Those are jobs for AGNTCY's own tooling and your configuration.

What a directory record points to, though, is ordinary software: a source repository, a container image, an MCP server package. That is where Safeguard works. You can scan the repository a locator names, the pinned image, or an SBOM the publisher supplies, and get vulnerability matches with reachability analysis:

safeguard scan --dir .                      # a cloned agent or MCP server repository
safeguard scan --image ghcr.io/example/agent@sha256:...   # the image a locator pins
safeguard scan --sbom agent-sbom.cdx.json   # an SBOM shipped with the agent

Results are written as JSON under ./output. The platform shows which of your projects contain a given component and version, so when a flaw lands in a library that many agents share, you can find every agent repository that carries it. Policies and gates in the platform can stop a build that does not meet your bar, and autonomous remediation can open fix pull requests (it ships switched off). MCP Guardrail, which generates guardrail proxy URLs for MCP servers so agent tool traffic passes through a policy point, is in early access. None of this tells you whether a directory publisher is who they claim to be; pinned verification does that.

An agent directory only tells you where an agent's code lives; the agent itself is built from open source packages and container base images that need patching like any other software. When a vulnerability lands in a library shared by many agents or MCP servers, the window between a fix existing and that fix running in every agent you depend on is where the risk sits.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which Safeguard tools Claude may use. It is the same decision this post keeps returning to: which server you trust, and which tools it is allowed to expose, chosen deliberately rather than picked up from a listing.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. It is how you would scan the repository a directory record's source_code locator points to, on your own hardware, before any agent runs that code.

Click through it at your own pace, or open it full screen.

The third demo is a real Safeguard CLI session. You ask it to fix a lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with your approval and pushes nothing. The same approval flow applies when the outdated dependency sits inside an MCP server or agent you found through a directory.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• AGNTCY home page
• AGNTCY documentation home
• Linux Foundation: Linux Foundation Welcomes the AGNTCY Project (29 July 2025)
• Linux Foundation: Linux Foundation Announces the Formation of the Agentic AI Foundation (9 December 2025)
• Linux Foundation: Linux Foundation Launches the Agent2Agent Protocol Project (23 June 2025)
• GitHub: agntcy organization
• OASF repository README
• AGNTCY docs: Open Agentic Schema Framework
• AGNTCY docs: Creating an Agent Record
• AGNTCY docs: OASF Translation Service
• Agent Directory repository README
• Agent Directory docs: Overview
• Agent Directory docs: Quickstart
• Agent Directory docs: Security Trust Model
• Agent Directory docs: Identity and Ownership Claims
• Agent Directory docs: Records and Validation
• Agent Directory docs: Content Policy Enforcement
• Agent Directory docs: CLI Reference
• Agent Directory release v1.8.0
• SLIM repository README
• SLIM docs: Architecture
• SLIM docs: Authentication
• SLIM docs: Naming
• SLIM docs: Groups
• AGNTCY Identity repository README
• AGNTCY Identity specification: Introduction
• IETF Datatracker: draft-mp-agntcy-ads, Agent Directory Service
• IETF Datatracker: draft-mpsb-agntcy-slim, SLIM
• A2A Protocol Specification
• Model Context Protocol: The MCP Registry
• Model Context Protocol: Security Best Practices (2025-11-25)
• Model Context Protocol: Tools (2025-11-25)
• RFC 9420: The Messaging Layer Security (MLS) Protocol

Last reviewed: 24 October 2026. AGNTCY components release often; check each repository's latest release notes and documentation before relying on a specific flag or default.