The Agentic AI Foundation Explained: MCP and Agent Standards Governance

The Agentic AI Foundation (AAIF) is a directed fund of the Linux Foundation, announced on 9 December 2025, that gives agent standards a vendor neutral home. It launched with three contributed projects: the Model Context Protocol (MCP), the goose agent framework and AGENTS.md. A Governing Board drawn from member companies oversees the fund, while a Technical Committee admits projects and moves them through Sandbox, Growth, Impact and Emeritus stages.

That is the short answer. The longer one matters to anyone who installs an MCP SDK, writes an AGENTS.md file or lets a coding agent run commands, because a foundation changes who owns a project's name, who can merge to its repositories, where you report a vulnerability and what you can expect from its releases. This guide goes one level deeper than our explainers on how MCP messages, transports and authorization work, how Codex discovers AGENTS.md instructions and Linux Foundation versus Apache governance. Every rule, date and number below comes from the primary sources listed at the end: the Linux Foundation and Anthropic announcements, the AAIF's own site and governance repository, MCP's governance and security documents, the AGENTS.md site, OpenAI's Codex documentation and registry metadata for the official SDKs. Where a source left a question open, we say so.

Key takeaways

• The Linux Foundation announced the AAIF on 9 December 2025, with MCP, goose and AGENTS.md as founding project contributions. Anthropic's announcement the same day describes the AAIF as "a directed fund under the Linux Foundation" co-founded by Anthropic, Block and OpenAI.
• The AAIF has two governing layers: a Governing Board drawn from member companies, and a Technical Committee (TC) whose charter was adopted on 3 March 2026. Each Platinum member may appoint one TC representative.
• Projects join through a public GitHub proposal, must use an OSI approved permissive license, must transfer trademarks and other assets to the Linux Foundation and must adopt a Linux Foundation technical charter.
• The Project Lifecycle Policy (first created 18 March 2026, updated 15 October 2026) defines Sandbox, Growth, Impact and Emeritus stages. MCP, goose and AGENTS.md are listed at Impact; agentgateway, Agent2Agent (A2A) and Agent Router at Growth.
• Anthropic said MCP's own governance "will remain unchanged" after the donation. MCP still runs on a maintainer hierarchy with Lead Maintainers, Core Maintainers and Specification Enhancement Proposals (SEPs), and membership is held by individuals, not companies.
• MCP's security policy routes reports through GitHub private vulnerability reporting, coordinates fixes across all official SDKs and assigns CVEs through GitHub's CNA. It also spells out what MCP does not treat as a vulnerability, such as command execution by the stdio transport.
• Foundation membership is a governance signal, not a security guarantee. You still verify each release yourself, and the step by step section below shows how.

What is the Agentic AI Foundation?

The AAIF is a home for open protocols and open source projects used to build AI agents. Its own About page calls it "a neutral, open foundation under the Linux Foundation" and lists MCP, goose, AGENTS.md, Agent2Agent and agentgateway among the projects it hosts. The AAIF's GitHub organization README repeats the mission statement from the launch press release: to ensure agentic AI "evolves transparently, collaboratively" and in ways that advance adoption of open source AI projects.

When was it announced?

The Linux Foundation published the formation announcement on 9 December 2025, datelined San Francisco. Anthropic published its own announcement, "Donating the Model Context Protocol and establishing the Agentic AI Foundation", on the same date. Both are primary sources, and they agree on the date, the founding projects and the directed fund structure.

Which projects were contributed at launch?

Three projects were contributed at launch, according to the Linux Foundation announcement:

Anthropic's announcement adds context on MCP at the time of the donation: more than 10,000 active public MCP servers, adoption by products including ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, an official community driven MCP Registry, official SDKs in all major languages and more than 97 million monthly SDK downloads across Python and TypeScript. It also notes that the 25 November 2025 specification release introduced asynchronous operations, statelessness, server identity and official extensions.

We could not load OpenAI's own AAIF announcement (openai.com returned HTTP 403 to our fetches), so the OpenAI role in the table above is attributed to the Linux Foundation's announcement. OpenAI's own Codex documentation, which we did read, describes how Codex discovers and merges AGENTS.md files; we cover that below.

Which projects does the AAIF host today?

The project list has grown since launch. As of 24 October 2026, the AAIF Projects page lists ten projects: Agent Router, Agent Skills, Agent2Agent (A2A), AGENTS.md, agentgateway, goose, Model Context Protocol, Open Responses, OpenEnv and OpenSandbox. The Technical Committee README on GitHub records a lifecycle stage for six of them:

When the website and the TC README disagree or one is missing an entry, treat the TC repository as the governance record and check its commit history for the date a stage changed.

What happened to Agent Skills?

On 22 October 2026 Anthropic announced that it was donating Agent Skills to the AAIF. Anthropic describes a skill as a folder containing a SKILL.md file that teaches an agent a task or domain, with any scripts or reference material it needs. Anthropic says it published Agent Skills as an open standard in December 2025, that more than 70 agent platforms have integrated it, and that it is donating the name and logo, the GitHub organization and the agentskills.io domain. Engineers from several companies will maintain the standard as individuals, with David Soria Parra and Mahesh Murag as Lead Maintainers. Anthropic also says it proposed a roadmap covering versioned releases, a formal proposal process and "security guidance for people who write and install skills." You can keep using or contributing to the standard without joining the AAIF.

How is the AAIF governed?

The AAIF uses the Linux Foundation's directed fund model. In practice that means three layers: the Linux Foundation as the legal entity that holds assets and employs staff, a Governing Board funded by members, and a Technical Committee for project decisions. Each hosted project then keeps its own technical governance underneath.

What is a directed fund?

The phrase appears in two primary sources we read. Anthropic's announcement calls the AAIF "a directed fund under the Linux Foundation." The AAIF TC charter opens by describing the AAIF as "a directed fund of The Linux Foundation." In plain terms, the Linux Foundation administers the fund for a defined purpose, and a member Governing Board directs it; the TC charter describes the TC as created by, and answerable to, that board. The TC charter also says that if it ever conflicts with "the AAIF charter or an action of the Governing Board," the AAIF charter controls. We did not find the AAIF's own top level charter published as a standalone document, so we describe the Governing Board's powers only as far as the TC charter references them.

Who sits on the Governing Board?

The AAIF About page lists the current Governing Board: representatives of the Platinum members, a Gold member representative and a senior advisor, with a chair and a treasurer. The Linux Foundation's launch announcement named eight Platinum members at formation, among them the three co-founders, Amazon Web Services, Bloomberg, Google and Microsoft. It also listed 18 Gold and 23 Silver members. The current roster and individual names are on aaif.io and change over time, so check the page rather than relying on a snapshot.

What does the Technical Committee do?

The TC charter, adopted on 3 March 2026, gives the TC a narrow, practical remit. The Governing Board set it up to review project proposals, recommend projects that fit the AAIF mission and apply the Project Lifecycle Policy. Its listed duties are to run working groups, coordinate projects and set technical priorities, recommend projects and resource priorities to the board, decide lifecycle stage changes, elect a chair each year and maintain the Lifecycle Policy with board approval.

Composition is simple: each Platinum member may appoint one TC representative. The TC README lists eight members, says all founding members were appointed by the Governing Board and gives the current term as 1 March 2026 to 31 December 2026.

How does the TC vote?

The charter sets out four rules worth knowing if you ever propose a project:

What are the working groups?

The AAIF website lists seven working groups and one cross group workstream: Accuracy and Reliability; Agentic Commerce; Governance, Risk and Regulatory Alignment; Identity and Trust; Observability and Traceability; Security and Privacy; Workflows and Process Integration; and the Taxonomy and Landscape workstream. Each has a public repository under github.com/aaif. The Security and Privacy group describes its aim as setting a benchmark for secure agentic operations, with a focus on security by design, standard practices and adversarial testing methods. The Governance, Risk and Regulatory Alignment group lists regulatory mapping such as the EU AI Act among its topics. Working groups produce guidance; they do not control project releases.

How do projects join, and what do the stages mean?

The Project Lifecycle Policy requires every proposal to be filed in the public aaif/project-proposals repository with a long list of facts. Several of them are supply chain facts, which is the useful part for a security reader. A proposal must state:

• the OSI approved permissive license the project uses
• the location of the public repository
• its automated validation and delivery or release processes, which must be public facing
• its release methodology and mechanics
• a public contribution process for specifications
• a public issue tracker
• its external dependencies and their licenses
• its core maintainers and decision making process, plus a GOVERNANCE.md if one exists

An OpenSSF Best Practices badge is listed as optional. Two conditions are mandatory for any project that joins: the existing host transfers trademarks and other project assets to the Linux Foundation, and the project adopts a technical charter in a form the Linux Foundation provides or approves, which sets the IP policy and decision making rules.

The stages then set expectations:

Every project also faces an annual review that asks for a written update on maintainership, community activity, release cadence, "security posture" and progress against objectives. That clause is the closest thing in the policy to a security requirement, and it is a reporting duty rather than a technical control.

What changes for MCP when it moves to a foundation?

Less than people expect in day to day engineering, and more than people expect in ownership. Anthropic's announcement states that "The Model Context Protocol's governance model will remain unchanged" and that maintainers will keep prioritizing community input and transparent decision making. The Lifecycle Policy, meanwhile, requires every AAIF project to transfer trademarks and assets to the Linux Foundation. Put together, the code, the specification process and the maintainers stay where they were, while the name and the neutral ownership move.

Who makes decisions in MCP?

The MCP governance page describes a hierarchy "similar to Python, PyTorch, and other open source projects":

Maintainers, Core Maintainers and Lead Maintainers together form the MCP Steering Group. The governance page names two current Lead Maintainers, David Soria Parra and Den Delimarsky, and six Core Maintainers, with four people listed as emeritus. The most important line for neutrality is this one: membership "is for individuals, not companies," there are no reserved company seats, and membership follows the person rather than their employer. Core Maintainers meet every two weeks, and the page says all decisions and their supporting discussion must be recorded on the shared maintainer Discord.

How does the specification change?

Through Specification Enhancement Proposals. The SEP guidelines say a SEP is required for new features or protocol changes, breaking changes, governance or process changes, and complex or contested topics. Bug fixes, typos, documentation clarifications and small schema fixes skip the process. Prior discussion with the relevant working or interest group is mandatory, and the pull request must link to it. There are four SEP types: Standards Track, Informational, Process and Extensions Track. The SEP template includes a "Security Implications" section, and SEPs live as Markdown files in the specification repository so their history is the record.

The 2025-11-25 specification changelog shows the process at work. Changes since the 2025-06-18 revision include OpenID Connect Discovery support for authorization servers, incremental scope consent through WWW-Authenticate (SEP-835), OAuth Client ID Metadata Documents as a recommended client registration method (SEP-991), URL mode elicitation (SEP-1036), tool calling in sampling (SEP-1577) and experimental tasks for durable requests (SEP-1686). Each traces back to a numbered SEP you can read.

What about the trademark and neutrality?

The trademark transfer is the main structural change a foundation brings. Under the Lifecycle Policy, a project joining the AAIF transfers its trademarks and other assets to the Linux Foundation, and Emeritus projects keep that arrangement: "the foundation will continue to hold the IP and any trademarks and domains." The AGENTS.md website footer already reflects this model, reading "Copyright © AGENTS.md a Series of LF Projects, LLC." For buyers, the practical effect is that no single member company can rename, relicense or withdraw the project name on its own. It does not change who writes the code; that remains the maintainers, chosen under each project's rules.

What MCP did not change

It is worth listing what a foundation move does not do, because vendor marketing sometimes blurs it:

• It does not audit every MCP server. The 10,000 plus public servers Anthropic mentions are written and published by thousands of independent authors.
• It does not change the trust model. MCP's own security policy says clients trust the servers they connect to and local servers are trusted "like any other software you install."
• It does not replace your review. The Lifecycle Policy's security scanning benefit is not even available at Sandbox stage.

What is AGENTS.md and how is it meant to be used?

AGENTS.md is plain Markdown placed in a repository to tell coding agents how to work on that project. The AGENTS.md site describes it as "a README for agents": a predictable place for build steps, test commands, conventions and other context that would clutter a human README. It reports use by more than 60,000 open source projects.

What goes in it?

There are no required fields. The site suggests sections such as a project overview, build and test commands, code style guidelines, testing instructions and security considerations, and it suggests adding commit message and pull request rules, security gotchas and deployment steps. A minimal file looks like this:

# AGENTS.md

## Setup
- Install dependencies: `npm ci`
- Run tests: `npm test`

## Conventions
- TypeScript strict mode
- Never add a production dependency without asking

## Security
- Do not run install scripts from new packages without review
- Never commit files under `config/secrets/`

How do agents resolve several files?

The AGENTS.md site gives two rules. In a monorepo you can place nested AGENTS.md files in subprojects, and "the closest AGENTS.md to the edited file wins." Explicit user chat prompts override everything. The site also answers a question security teams should notice: agents will run the testing commands listed in AGENTS.md and try to fix failures before finishing.

Individual agents add their own details. OpenAI's Codex documentation describes a precise discovery chain:

1. Global scope. In the Codex home directory (by default ~/.codex), Codex reads AGENTS.override.md if present, otherwise AGENTS.md.
2. Project scope. From the project root (usually the Git root) down to the current directory, Codex checks each directory for AGENTS.override.md, then AGENTS.md, then any configured fallback names, and includes at most one file per directory.
3. Merge order. Files are concatenated from the root down, so files closer to the working directory appear later and take precedence.

Codex skips empty files and stops once the combined size reaches project_doc_max_bytes, which the documentation gives as 32 KiB by default. Our Codex AGENTS.md discovery post walks through that chain with examples.

Why does AGENTS.md matter for security?

Because an agent treats it as instructions. Any file that an agent reads and acts on is part of your attack surface in the same way a CI workflow file is. Three practical consequences follow:

• Review it like code. Changes to AGENTS.md in a pull request should get the same scrutiny as a change to a build script, especially new commands under "testing" or "setup."
• Watch nested and override files. A nested AGENTS.md or an AGENTS.override.md in a subdirectory can change behaviour only for edits in that directory, which makes it easy to miss in review.
• Keep secrets out. AGENTS.md is committed to the repository and read into model context; credentials do not belong there.

How does the AAIF relate to other agent protocol homes?

Agent2Agent (A2A)

A2A started outside the AAIF. On 23 June 2025 the Linux Foundation announced the launch of the Agent2Agent project, describing A2A as "an open protocol created by Google" for agent to agent communication, launched by Google in April 2025 with support from more than 100 companies. The A2A README says the protocol is "an open source project under the Linux Foundation, contributed by Google," licensed under Apache 2.0.

As of 24 October 2026, A2A appears on the AAIF Projects page, on the AAIF About page and in the AAIF TC README at Growth stage. We could not find a dated primary announcement of A2A moving into the AAIF, so we cannot give you a date for that transfer. A2A's own GOVERNANCE.md still describes a Technical Steering Committee with nine seats, each held by a company, which differs from MCP's individual only model. If you depend on both, read both governance files: they answer the question "who can approve a breaking change" differently.

The OpenSSF AI/ML Security Working Group

The Open Source Security Foundation is another Linux Foundation community, with a mission to "inspire and enable the community to secure the open source software we all depend on." Its AI/ML Security Working Group studies security risks from LLMs, generative AI and other AI or ML systems and their impact on open source projects and maintainers. Its listed projects include OpenSSF Model Signing (OMS), a library and CLI to sign and verify ML models, and OSS-CRS, an orchestration framework for LLM based bug finding and bug fixing systems. The group also publishes guidance on securing agentic AI. The split of work is roughly this: the AAIF hosts the agent protocols and tools themselves, and the OpenSSF publishes cross cutting security practice that applies to them. Our OpenSSF explainer covers its structure in depth.

Where the boundaries sit

What does foundation governance mean for supply chain trust in agent tooling?

A foundation gives you durable answers to three questions: who owns the name, how decisions are made, and where to report a problem. It does not, by itself, tell you whether a particular release was built from the code you think it was. For that you check the project's security policy, its release process and the attestations on its packages. Here is what we found for MCP and its neighbours.

Vulnerability disclosure

The MCP specification repository's SECURITY.md asks researchers to report through GitHub's private Security Advisory process and not through public issues, discussions or pull requests. Its "SDK Vulnerability Disclosure" section adds three commitments that matter for downstream users:

• Private vulnerability reporting "is enabled on every official SDK repository" in the modelcontextprotocol organization.
• When a report arrives, that SDK's maintainers assess whether the same issue affects other official SDKs and coordinate so fixes and advisories ship together "rather than leaving some SDKs exposed after others have published."
• CVEs are assigned through GitHub's CNA as part of the GitHub Security Advisory workflow.

The policy also defines the trust model and lists behaviours that are not vulnerabilities. Command execution by clients using the stdio transport is "expected behavior," because a stdio client starts a server by running a command you configured. The stdio channel "is not a sandbox," and a malicious server "already has arbitrary code execution by virtue of being run." Servers doing what they are documented to do, such as file access, git operations, database queries or running system commands, are features. An LLM choosing a tool the user did not explicitly request is treated as model and application behaviour, not an MCP vulnerability.

What remains in scope: protocol level flaws, authentication and authorization bypasses, SDK implementation bugs, sandbox escapes from isolation boundaries the protocol or SDKs define, session hijacking, token theft or leakage, and cross tenant access in multi tenant deployments.

A2A's SECURITY.md is short: report through GitHub Security Advisories on the a2aproject/A2A repository, which the project uses "for private intake, coordination, and disclosure." goose's SECURITY.md opens with a caution that goose is a developer agent that can act on the local machine, and recommends running it in a dedicated virtual machine or container, reviewing generated code, requiring human confirmation for significant changes and connecting only MCP extensions you have reviewed.

Supported versions

The MCP Python SDK publishes an explicit support table. As of 24 October 2026:

The policy notes that only the newest release of a supported line receives fixes, and suggests pinning mcp<2 if you are not ready for 2.x. The TypeScript SDK's SECURITY.md, by contrast, covers reporting only and has no supported versions table at the time of writing.

Release signing and provenance

Both official SDKs we checked publish build provenance through their registries:

Registry provenance tells you which repository and workflow produced a file. It does not tell you that the code in that repository is safe, and it covers only the packages that publish it. Many community MCP servers do not.

Where governance helps, and where it stops

Step by step: check an AAIF project's policies and one MCP SDK release

The commands below read public metadata. They do not change anything on your machine except downloading one package file into a scratch directory. You need git, curl, jq, the GitHub CLI (gh) signed in, Node.js with npm, and Python 3 with pip.

Step 1: list the AAIF projects and their stages

Start from the governance record, not the marketing page.

# Read the Technical Committee README, which lists project stages
gh api repos/aaif/technical-committee/contents/README.md \
  --jq '.content' | base64 --decode | sed -n '/## Projects/,/Do you want/p'

# Read the lifecycle policy and charter
gh api repos/aaif/technical-committee/contents/governance/project-lifecycle-policy.md \
  --jq '.content' | base64 --decode | head -n 40
gh api repos/aaif/technical-committee/contents/governance/charter.md \
  --jq '.content' | base64 --decode | head -n 30

# See when the stage table last changed
gh api "repos/aaif/technical-committee/commits?path=README.md&per_page=5" \
  --jq '.[] | [.commit.author.date, .commit.message] | @tsv'

Step 2: find each project's security policy and governance files

GitHub's community profile endpoint reports which health files a repository has.

for repo in modelcontextprotocol/modelcontextprotocol \
            modelcontextprotocol/typescript-sdk \
            modelcontextprotocol/python-sdk \
            a2aproject/A2A \
            agentsmd/agents.md; do
  echo "== $repo"
  gh api "repos/$repo/community/profile" \
    --jq '{health: .health_percentage,
           contributing: (.files.contributing != null),
           code_of_conduct: (.files.code_of_conduct != null),
           license: .files.license.spdx_id}'
  # SECURITY.md can live in the repo root, .github/ or docs/
  for p in SECURITY.md .github/SECURITY.md docs/SECURITY.md; do
    gh api "repos/$repo/contents/$p" --silent 2>/dev/null && echo "security policy: $p"
  done
  for p in GOVERNANCE.md CONTRIBUTING.md OWNERS.md MAINTAINERS.md; do
    gh api "repos/$repo/contents/$p" --silent 2>/dev/null && echo "has $p"
  done
done

Then confirm private vulnerability reporting is switched on, as MCP's policy says it is for official SDKs:

gh api repos/modelcontextprotocol/python-sdk/private-vulnerability-reporting
gh api repos/modelcontextprotocol/typescript-sdk/private-vulnerability-reporting
# Expected output for each: {"enabled":true}

If a project you depend on returns {"enabled":false} and has no SECURITY.md, you have learned something important about how a vulnerability report would reach its maintainers.

Step 3: read the release process

The Impact stage criteria require a "publicly accessible description of the project's roadmap and release processes." Look for it in the repository and in the CI workflows that publish packages.

# Recent releases and tags
gh release list -R modelcontextprotocol/python-sdk --limit 5
gh release list -R modelcontextprotocol/typescript-sdk --limit 5

# The workflows that publish to the registries
gh api repos/modelcontextprotocol/python-sdk/contents/.github/workflows \
  --jq '.[].name'
gh api repos/modelcontextprotocol/python-sdk/contents/.github/workflows/publish-pypi.yml \
  --jq '.content' | base64 --decode | grep -nE 'permissions|id-token|environment|pypa/gh-action-pypi-publish' 

You are checking three things: that publishing runs from CI rather than a laptop, that it uses short lived OIDC credentials (id-token: write) rather than a stored token, and that it runs in a protected environment such as release.

Step 4: verify the npm SDK release

mkdir -p /tmp/mcp-check && cd /tmp/mcp-check
npm init -y >/dev/null
npm install @modelcontextprotocol/sdk@1.32.2 --ignore-scripts

# Confirm registry signatures and provenance attestations for installed packages
npm audit signatures

# Inspect the provenance record for this exact version
npm view @modelcontextprotocol/sdk@1.32.2 dist.attestations --json
curl -s "https://registry.npmjs.org/-/npm/v1/attestations/@modelcontextprotocol%2fsdk@1.32.2" \
  | jq '.attestations[] | .predicateType'

npm audit signatures reports how many packages have verified registry signatures and how many have verified attestations. The attestation record should point back to github.com/modelcontextprotocol/typescript-sdk and to the workflow that built it. If the source repository in the provenance does not match the repository named in package.json, stop and investigate.

Step 5: verify the PyPI SDK release

mkdir -p /tmp/mcp-py && cd /tmp/mcp-py
python3 -m pip download mcp==2.3.0 --no-deps --only-binary=:all: -d .

# Check the hash against the one PyPI publishes
sha256sum mcp-2.3.0-py3-none-any.whl
curl -s https://pypi.org/pypi/mcp/2.3.0/json \
  | jq -r '.urls[] | select(.filename=="mcp-2.3.0-py3-none-any.whl") | .digests.sha256'

# Read the provenance PyPI holds for this file
curl -s https://pypi.org/integrity/mcp/2.3.0/mcp-2.3.0-py3-none-any.whl/provenance \
  | jq '.attestation_bundles[].publisher'

# Optional: cryptographically verify it with the pypi-attestations tool
python3 -m pip install pypi-attestations
pypi-attestations verify pypi \
  --repository https://github.com/modelcontextprotocol/python-sdk \
  pypi:mcp-2.3.0-py3-none-any.whl

The publisher block should name repository modelcontextprotocol/python-sdk, workflow publish-pypi.yml and environment release, matching what you saw in Step 3. The pypi-attestations command options can change between versions of that tool, so check pypi-attestations verify pypi --help if the syntax above fails.

Step 6: check the release against the policies you read

Now put the pieces together for the version you are about to deploy:

# Published advisories for each SDK
gh api repos/modelcontextprotocol/python-sdk/security-advisories \
  --jq '.[] | [.ghsa_id, .cve_id, .severity, .published_at] | @tsv'
gh api repos/modelcontextprotocol/typescript-sdk/security-advisories \
  --jq '.[] | [.ghsa_id, .cve_id, .severity, .published_at] | @tsv'

Step 7: pin and record what you verified

# Python: pin with hashes so a later install cannot silently change the file
echo "mcp==2.3.0 --hash=sha256:<hash from step 5>" > requirements.txt
python3 -m pip install --require-hashes -r requirements.txt

# Node: commit the lockfile and install from it in CI
npm ci --ignore-scripts

Record the version, the verification date and the provenance publisher next to the lockfile, and repeat Steps 4 to 6 before every bump.

How do the AAIF, OpenSSF, CNCF and the Eclipse Foundation compare?

These four organisations are often mentioned together. They are not ranked here; they do different jobs.

You can contribute to any AAIF project without being a member. Anthropic's Agent Skills announcement says so explicitly for that project, and the TC README points contributors to each project's CONTRIBUTING.md. Membership can bring a seat on the Governing Board or the TC; it does not bring merge rights in a project.

For the Eclipse column, our Eclipse Foundation explainer has the details and its own sources. For how the Linux Foundation's foundation model differs from the Apache model, see Linux Foundation vs Apache governance. The OpenJS Foundation explainer is a useful comparison for a foundation with a long running security program.

Common mistakes

• Treating "under the Linux Foundation" as a security certification. The Lifecycle Policy says Sandbox status "is not an endorsement," and Sandbox projects are not eligible for security scanning. Even Impact status reflects adoption and governance, not an audit result.
• Assuming every MCP server is an AAIF project. The foundation hosts the protocol and official SDKs. Community servers are separate software with separate owners.
• Filing stdio command execution as a vulnerability. MCP's security policy lists it as intended behaviour. Spend review time on what the configured command does instead.
• Reading the website instead of the governance repository. The AAIF site lists ten projects; the TC README records stages for six. Use the repository as the record and its commit history for dates.
• Confusing membership with maintainership. MCP's governance gives roles to individuals, not companies. A2A's TSC gives seats to companies. Do not assume one model across projects.
• Skipping provenance because the package name looks right. The name is a registry account. Provenance ties the file to a repository and workflow.
• Leaving AGENTS.md out of code review. It changes what an agent will run. Treat it like a build file.

FAQ

What is the Agentic AI Foundation?

The Agentic AI Foundation (AAIF) is a directed fund of the Linux Foundation that hosts open protocols and open source projects for AI agents, including the Model Context Protocol, AGENTS.md, goose, Agent2Agent and, since 22 October 2026, Agent Skills. It has a Governing Board drawn from member companies and a Technical Committee that manages project stages.

When was the Agentic AI Foundation announced?

The Linux Foundation announced the formation of the AAIF on 9 December 2025. Anthropic announced its donation of MCP to the AAIF on the same day.

Who founded the AAIF?

Anthropic's announcement says the AAIF was co-founded by Anthropic, Block and OpenAI. The Linux Foundation's announcement listed eight Platinum members at launch, along with 18 Gold and 23 Silver members.

Does Anthropic still control MCP?

Anthropic donated MCP to the AAIF and said MCP's governance model "will remain unchanged." Under the AAIF Lifecycle Policy, projects transfer trademarks and assets to the Linux Foundation. Technical decisions sit with MCP's maintainers, and MCP's governance page says maintainer roles belong to individuals, not companies.

Is AGENTS.md part of the Linux Foundation?

Yes. The AGENTS.md site says it "is now stewarded by the Agentic AI Foundation under the Linux Foundation," and its footer identifies it as a Series of LF Projects, LLC.

Is A2A part of the Agentic AI Foundation?

As of 24 October 2026, A2A is listed on the AAIF Projects page and in the AAIF Technical Committee README at Growth stage. The Linux Foundation first launched A2A as its own project on 23 June 2025. We could not find a dated announcement of its move into the AAIF.

How do I report a vulnerability in an MCP SDK?

Use GitHub's private vulnerability reporting on the affected SDK repository in the modelcontextprotocol organization. MCP's security policy says this is enabled on every official SDK repository, that maintainers coordinate across SDKs, and that CVEs are assigned through GitHub's CNA. Do not open a public issue.

How does a project join the AAIF?

By filing a proposal in the public aaif/project-proposals repository. The project needs an OSI approved permissive license, public release and contribution processes, a TC majority vote and Governing Board approval, and it must transfer trademarks to the Linux Foundation and adopt a Linux Foundation technical charter.

Is the AAIF the same as the OpenSSF?

No. Both are Linux Foundation communities, but the AAIF hosts agent protocols and tools, while the OpenSSF works on open source security practice across ecosystems. The OpenSSF's AI/ML Security Working Group publishes guidance that applies to agent tooling.

Where Safeguard fits

The fit here is practical and narrow. The AAIF governs standards; your exposure comes from the specific SDK versions, agent frameworks and MCP servers that end up in your repositories and container images. Safeguard scans repositories, container images and SBOM files for those components (safeguard scan --dir ., --image <name>, --sbom <file>), matches them against vulnerability databases, shows which projects contain a given component and version, and applies reachability analysis so you see which vulnerable code paths your application actually calls. Policies and gates evaluated in the platform can flag a vulnerable SDK version before it reaches a release. What Safeguard does not do is review the behaviour of a third party MCP server, decide whether a server's tools are safe to expose to a model, or replace the provenance checks in the walkthrough above. Those stay with your team.

Agent tooling is ordinary open source with a new label: MCP SDKs, agent frameworks and gateways are packages that sit in your lockfiles and images, and they pick up vulnerable transitive dependencies like anything else. A foundation improves how those projects are run, but the gap between a fix landing upstream and that fix running in your builds is still yours to close.

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 is allowed to use. It is a concrete example of the MCP client and server trust model discussed above: you decide which server to connect and which tools it may expose.

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

The second 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 dependency you are upgrading is an MCP SDK rather than lodash.

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

The third 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 a repository full of agent tooling without sending the code anywhere first.

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

• Linux Foundation: Linux Foundation Announces the Formation of the Agentic AI Foundation (9 December 2025)
• Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (9 December 2025)
• Anthropic: Donating Agent Skills to the Agentic AI Foundation (22 October 2026)
• Agentic AI Foundation: home page and working groups
• Agentic AI Foundation: About, Governing Board and Technical Committee
• Agentic AI Foundation: Projects
• AAIF GitHub organization
• AAIF Technical Committee README
• AAIF Technical Committee Charter (adopted 3 March 2026)
• AAIF Project Lifecycle Policy (updated 15 October 2026)
• AAIF project proposals repository
• Model Context Protocol: Governance
• Model Context Protocol: SEP Guidelines
• Model Context Protocol: Specification
• Model Context Protocol: 2025-11-25 specification changelog
• MCP specification repository SECURITY.md
• MCP Python SDK SECURITY.md
• MCP TypeScript SDK SECURITY.md
• npm registry metadata for @modelcontextprotocol/sdk
• PyPI JSON metadata for mcp
• PyPI provenance for mcp 2.3.0 wheel
• AGENTS.md
• OpenAI Codex documentation: Custom instructions with AGENTS.md
• Linux Foundation: Linux Foundation Launches the Agent2Agent Protocol Project (23 June 2025)
• A2A README
• A2A GOVERNANCE.md
• A2A SECURITY.md
• goose SECURITY.md
• OpenSSF: About
• OpenSSF: AI/ML Security
• CNCF: Who we are
• CNCF charter
• CNCF TOC project process
• OpenSSF: Projects
• Eclipse Foundation Development Process
• Eclipse Foundation: About

Last reviewed: 24 October 2026. AAIF project stages, working groups and board membership change over time; check the Technical Committee repository and each project's SECURITY.md before relying on a specific detail.