MCP Got Enterprise Auth. SAP Still Needs Guardrails
MCP's 2026-07-28 release brings a stateless core and stable enterprise-managed authorization. Neither decides what an agent may do inside SAP.
The Model Context Protocol's Enterprise-Managed Authorization extension, promoted to stable in July 2026, governs which AI agents may connect to which servers. It does not govern what an agent may do once connected. In an SAP landscape that gap is the entire job — the distance between an agent that can reach your ERP and an agent that can post a seven-figure sales order.
What actually shipped in the 2026-07-28 MCP release
On July 28, 2026, MCP maintainers David Soria Parra and Den Delimarsky published the 2026-07-28 specification. The headline change is a stateless protocol core: the initialize/initialized handshake and the Mcp-Session-Id header are retired, every request carries its own protocol version and client identity, and any request can land on any server instance behind a plain round-robin load balancer.
The rest is equally operational. Method and tool names now travel in Mcp-Method and Mcp-Name HTTP headers so gateways can route and authorize without parsing JSON bodies. List responses carry ttlMs and cacheScope hints. Multi Round-Trip Requests replace server-initiated calls that needed a held-open stream. Authorization was hardened with RFC 9207 issuer validation, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. The maintainers also committed to a twelve-month minimum deprecation window — a governance detail that matters more to an ERP team than any feature on the list.
Separately, the Enterprise-Managed Authorization (EMA) extension reached stable status, with Anthropic, Microsoft, and Okta named as adopters. As InfoQ reported, EMA moves the authorization decision into the corporate identity provider using an Identity Assertion JWT Authorization Grant, replacing per-server consent prompts with a single sign-in.
Where enterprise-managed authorization stops
The MCP project is refreshingly direct about the boundary. InfoQ's summary of the EMA guide notes that the extension "does not inspect the MCP traffic after the token is issued" and explicitly warns that this is not runtime authorization for individual actions.
The analogy is a badge reader at the lobby door. It decides who gets into the building and which floors they can reach. It has no opinion about whether the person who badged in may approve a purchase order once they sit down. EMA is a very good badge reader. SAP risk lives on the other side of the door.
That is not a criticism. Connection-level identity is the right scope for a transport protocol. But a CIO evaluating agentic AI for SAP should not read "MCP now has enterprise auth" as "MCP now governs what agents do to my ERP." Those are different control planes, and only one ships with the spec.
What runtime authorization looks like in SAP
The second control plane has to be built where the transaction happens. Four controls do most of the work:
Standard interfaces, standard authorizations. Agents call released BAPIs and OData services under a service user with a scoped role, so SAP's own authorization objects still adjudicate every call. No direct table writes, no superuser shortcuts, no clean-core violations to unwind at the next upgrade.
Simulate before you create. Order, pricing, and availability logic all have simulation variants. Run the simulation, surface the delta, then commit. An agent that can only propose until a rule or a human clears it has a fundamentally different risk profile than one that writes on first pass.
Deterministic guardrails outside the model. Value thresholds, credit blocks, customer and material validity, duplicate-PO checks — these belong in code, not in a prompt. Language models are good at extraction and reconciliation and unreliable as a policy engine.
An audit record per action. What the agent proposed, what document evidence it read, which rule or person approved it. This is what internal audit asks for, and it is the artifact that turns a pilot into a production system.
Across its own production deployments, SayfeAI has processed 98,989+ orders with roughly 95% touchless throughput and 99.2% accuracy. Those are SayfeAI's aggregate figures across three or more production customers, not any single customer's result — and they are a function of that guardrail stack far more than of any model choice.
Why the stateless turn helps self-hosted deployments
There is a quieter strategic point in this release. Sticky sessions and shared session stores were a real reason MCP servers gravitated to managed cloud platforms. A stateless core means an MCP server can run inside your own VPC behind ordinary infrastructure, with your data never leaving your boundary. AWS VP of Agentic AI Swami Sivasubramanian noted the stateless core is available in Amazon Bedrock AgentCore, letting teams "deploy MCP servers on standard, scalable infrastructure without managing sessions or persistent connections."
For mid-market SAP shops that were told self-hosting agentic AI was impractical, the infrastructure argument just got weaker.
A note on names: SayfeAI (sayfe.ai) is the self-hosted agentic AI platform for mid-market SAP discussed here. It is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner that deploys ChatGPT Business for small and midsize businesses.
Frequently asked questions
Does the new MCP specification make it safe to connect AI agents to SAP?
It makes the connection layer safer and far easier to operate, but safety in SAP is decided by what the agent is permitted to execute. MCP's EMA extension controls which clients reach which servers; it does not evaluate individual tool calls. You still need SAP authorization objects, simulation-first write patterns, deterministic business rules, and an audit trail.
Do we have to rewrite our existing MCP servers?
Servers that depend on session identifiers will need migration work, since the handshake and Mcp-Session-Id header are retired. The maintainers have updated the TypeScript, Python, Go, and C# SDKs with migration notes, deprecated features keep working for at least twelve months, and Dynamic Client Registration should be replaced with Client ID Metadata Documents on your next auth pass.
Is this an alternative to SAP Joule?
It is an ownership question rather than a competitive one. Joule is a strong fit for organizations standardizing on SAP BTP and comfortable with SAP-managed AI consumption. A self-hosted MCP architecture suits companies that want the agent layer, the model choice, and the data boundary under their own control. Many landscapes will end up running both.