Four New Projects, Ten Total: What the Agentic AI Foundation's Additions Actually Prove

At AGNTCon + MCPCon North America 2026, the Agentic AI Foundation added OpenSandbox, Open Responses, Agent Skills, and OpenEnv, reaching ten projects in its first year. ¹ For teams evaluating AI agent infrastructure, the more useful signal may be the conference themes: the source says keynotes focused on MCP in production, security, and agents with their own identities. ¹

That focus is a reason to sharpen your evaluation process, not a reason to assume a newly announced project is ready for your control plane. The available source excerpt confirms the additions and names those themes; it does not establish the projects' maturity, adoption, security track record, or interoperability. ¹

What actually happened at AGNTCon + MCPCon

The source reports that the foundation reached ten projects in its first year, with four additions announced at the conference. ¹ This suggests ecosystem activity, but it does not establish whether any of the additions meets your security, operational, or compatibility requirements. The excerpt provides no production-readiness results or adoption figures for them. ¹

Treat project formation as a prompt to investigate, not as proof that an enterprise requirement has been satisfied. A project can be relevant to your architecture and still require documentation, operational ownership, or implementation evidence before deployment. That is a diligence question, not a conclusion about these projects.

What OpenSandbox and the other new projects are supposed to solve

The excerpt names OpenSandbox, Open Responses, Agent Skills, and OpenEnv, but does not describe their purposes, technical specifications, maturity, or deployment evidence. ¹ Names alone don't tell you what a tool does or where its trust boundaries sit. Resist the urge to fill that gap by inference.

Project	Stated purpose in the excerpt	Interfaces, trust boundaries, identity model, deployment evidence
OpenSandbox	Not specified in the excerpt 1	Not specified in the excerpt 1
Open Responses	Not specified in the excerpt 1	Not specified in the excerpt 1
Agent Skills	Not specified in the excerpt 1	Not specified in the excerpt 1
OpenEnv	Not specified in the excerpt 1	Not specified in the excerpt 1

Run a project review. Ask maintainers for the scope, interface definition, reference implementation, threat model, compatibility claims, release policy, and known limitations. Record what's documented, what's been tested, and what's still an open question. This isn't a verdict on whether these projects have value; it marks what the available reporting establishes.

Why MCP security and agent identity are the sharper signal

The source says keynotes from Anthropic, OpenAI, Google, and UC Berkeley focused on MCP in production, security, and agents with their own identities. ¹ That establishes the conference themes, not a control specification or a reference implementation of agent identity. ¹ If you are still deciding how agents should reach tools in the first place, see MCP or CLI for AI agents: what the evidence actually supports.

For a platform team, agent identity matters when a system can act on a service or tool on someone's behalf. A useful design review separates the human who requested the work, the agent software making the call, the runtime executing it, and the authority granted for that task. If those roles are blurred, it may be harder to determine from logs whose permissions allowed an action.

Make the identity questions concrete before you sign off on anything:

• Who issues an agent's identity, and how does a downstream service verify it?
• What actions can that identity authorize, and how is it scoped to tools, resources, or tenants?
• How is authority delegated from a human or service to an agent, and how is that delegation represented in a request?
• How are credentials rotated, revoked, and audited?
• Given a log entry, can you identify which agent identity acted and which policy permitted it?

These are evaluation questions, not capabilities the source confirms. ¹ A good answer describes the intended design and the implementation's observed behavior under test.

What production MCP security needs to prove

A production conversation should end in evidence about controls, not merely a claim that a system supports MCP. The source mentions security as a conference theme, but does not specify which controls were discussed or endorse a particular implementation. ¹

Separate authentication from authorization in your review. Authentication is how a client proves who it is; authorization is what that verified caller is allowed to do. A system that verifies identity but grants broad access may still fall short of least-privilege operation.

What to check:

• Tool access. Are tools allow-listed? Can permissions be scoped to specific actions rather than whole tool categories?
• Input and output handling. What happens with malformed inputs, unexpected outputs, or attempts to manipulate tool behavior during a call?
• Secrets. Are credentials kept out of model-visible content and scoped to the task?
• Auditability. Do records connect the requester, agent identity, tool call, authorization decision, and result?
• Operations. What happens when a dependency is unavailable, a request times out, or an operator needs to revoke access immediately?

Don't stop at a written security design. Ask for negative tests: unauthorized calls, expired credentials, replayed requests, malformed inputs, unavailable dependencies, and attempts by an agent to exceed its assigned task. Look at how the system behaves when controls are tested, not just how its intended flow is described.

Interoperability is not readiness

Sharing a project or interface can reduce integration work. It is not the same as verified compatibility, and the available excerpt does not establish interoperability for any of the new projects. ¹

Test the implementation against the systems you actually run, under your own authentication, network, data-handling, and audit requirements. A successful request between components does not by itself establish that identity, authorization, and audit context survive a multi-step workflow. Setup overhead is one more thing to measure; measuring the setup cost of agent-to-agent communication covers that angle.

Run a bounded pilot. Before it starts, decide what you need to observe: successful and rejected calls, authorization failures, audit completeness, latency under expected load, recovery behavior, and the effort required to swap or remove a tool. These are measures for your evaluation; the source reports no results on them. ¹ Include scenarios where users leave things unstated, as discussed in Tool-Using Agents Need Tests for Users Who Leave Things Unsaid.

If cross-provider or cross-runtime behavior matters to your architecture, test it explicitly. Don't infer compatibility from a project's presence in a foundation or its visibility at a conference. ¹ A pilot should tell you which components work together, under which configurations, and what breaks when a component changes or becomes unavailable.

Before adopting any of this tooling

Build a control matrix. For each candidate project or implementation, note the expected behavior and the evidence you'd need for:

• identity and delegated authority
• authorization and tool access
• secrets and network access
• data handling and audit logging
• incident response and credential revocation
• versioning, compatibility, and operational ownership

Then pin down exactly what you're evaluating: the implementation and version, its dependencies, deployment boundary, exposed tools, required credentials, and rollback path. The source excerpt doesn't provide these details; this is diligence the announcement can prompt. ¹ If model traffic also passes through an enterprise AI gateway, apply the same evidence questions to that layer.

Start with read-only or otherwise low-impact actions. Use narrowly scoped identities. Require human approval for irreversible operations until testing shows the automated controls behave as designed. Set a decision gate before the pilot: proceed only once scope, security model, interoperability behavior, operational owner, and test results are documented.

The source gives you a reason to look at these four projects and the security themes around them. It gives you no reason to skip the diligence you'd apply to other infrastructure touching production systems. ¹

What would change the readiness assessment

Look for a published specification, a maintained reference implementation, compatibility tests, security review materials, a vulnerability response process, release history, deployment guidance, and independently verifiable evidence of real use. The available excerpt does not establish whether these materials or evidence exist for the four new projects. ¹

Keep project-level evidence separate from implementation-level evidence. A well-documented design doesn't prove that a specific build handles identity lifecycle, enforces least privilege, or fails safely. A successful pilot of a particular implementation also doesn't establish how other implementations of the project behave.

Revisit the decision once a team can show that identities are issued and revoked as intended, permissions stay within scope, audit records support incident investigation, version changes have predictable effects, and failures don't silently grant excess authority. These are engineering criteria, not results reported in the source excerpt. ¹

Quick reference for a review meeting

What did the Agentic AI Foundation add?
OpenSandbox, Open Responses, Agent Skills, and OpenEnv, reaching ten projects in the foundation's first year. ¹

Does that prove the additions are production-ready?
No. The excerpt confirms the additions but doesn't establish their maturity, adoption, security track record, or interoperability. ¹

What did the conference source say about MCP security?
It says keynotes from Anthropic, OpenAI, Google, and UC Berkeley focused on MCP in production and security, but gives no detailed control specification. ¹ Assess authentication, authorization, tool isolation, auditing, and failure handling yourself.

What does agent identity mean in practice?
The excerpt identifies it as a conference theme, not as an implementation. ¹ Ask how identity is issued and verified, how delegated permissions work, how credentials are rotated and revoked, and how actions are audited.

How should a team evaluate these projects?
Treat the announcement as a reason to investigate, not a substitute for investigation. Request technical scope and evidence, then test identity, authorization, interoperability, observability, and failure behavior in a bounded pilot. The source excerpt does not report results for those evaluations. ¹

Set your decision gate before a vendor pitch references any of these projects: no production traffic until the control matrix is complete and the negative tests have run.