What happened
On December 9, 2025, Anthropic announced that it was donating the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation. MCP standardizes connections between AI applications and external systems. The announcement also says MCP's governance model remains unchanged: maintainers continue their existing community-led process.
That distinction matters. Moving a project into a foundation is a stewardship event. It does not automatically change the permissions of a connected application, certify a server or grant an assistant access to a business's records. This is a historical briefing on that announcement, not a new integration release.
The araNET take
The practical artifact for a business is a permission sheet written around one job. Here is an illustrative project-lookup assistant for a team that maintains several customers' websites. Its purpose is to answer an employee's question about an assigned project's latest approved status.
- Identity: use the signed-in employee's verified identity. A name supplied in the question does not establish which account they control.
- Record boundary: return only projects that employee may view within their business. A valid project identifier still needs an access check.
- Allowed read: project name, approved milestone status, latest shared update and the source record's date.
- Excluded read: unrelated customers, internal finance notes, credentials and unpublished proposals.
- Allowed output: a sourced summary for the requesting employee, with missing or stale information identified.
- Excluded actions: edit milestones, share files, invite people or send the summary outside the team.
These are proposed application rules, not standardized MCP scope names. The protocol's authorization specification addresses access to protected MCP servers; an implementer still has to map the business's own roles and record boundaries into enforceable checks.
Start with a narrow job
Turn the sheet into a small review exercise before adding more tools. Create two fictional businesses and an employee assigned to one. Ask for a permitted project, an unassigned project in the same business and a project belonging to the other business. The latter requests should fail without revealing the protected record's contents. Then request an edit and an external email: neither belongs to this assistant's authority.
Check the actual server response as well as the assistant's prose. A polite refusal is insufficient if the protected record was already returned to the model. Conversely, an authorized read should include enough provenance for the employee to notice an outdated status.
Finally, remove the employee's project access and repeat the request. Define how the connected application invalidates access and handles information it already retained; do not assume disconnecting a tool erases earlier copies. Record the expected behavior with the permission sheet.
Keep the permission sheet with the integration’s acceptance checks so a later connection or access change can be reviewed against the same boundaries.
