What happened since Part 1

Part 1 of this field guide came out in April. It covered the foundations: why passwords are the wrong tool and tokens are the right one, the four risk categories when AI touches planning data, and the options for keeping data inside your walls. It still holds. Since then, three things moved.

First, the MCP specification went final on July 28. The protocol became stateless, moving from the Smart View pattern (connect once, session expires, reconnect) to the REST pattern (every request complete on its own). I covered the changes in my July walkthrough.

Second, Enterprise Managed Authorization went stable in June. Single company login for AI connections. More on it below, because it changes how finance teams roll agents out.

Third, MCP security left the lab. In May, the NSA's AI Security Center published security guidance for systems built on MCP. In June, Microsoft published a full report on the state of MCP security. Security researchers now publish new findings about MCP servers almost every week. When institutions of that size start writing guidance, AI agents on business data have become a normal business subject.

The sentence to remember

Microsoft wrote it in their own report, and it deserves to be read twice: the protocol deliberately does not enforce security for you. The new rules make connecting safer. What the agent can see and do once connected was never the protocol's job.

The specification moved. The responsibility did not.

The scorecard: Part 1's four risks, rescored

Credential and token exposure

Improved

The new rules align tightly with OAuth, and tokens are now bound to the server that issued them, which blocks a known redirection trick. A clear step forward, and credit to the people behind it.

Over-broad access for the agent's login

Unchanged, and always will be

The specification cannot see your EPM security model. If the login behind your agent can open workforce data, your agent can open workforce data. Entirely yours to manage.

Flaws inside MCP servers

Mixed

The protocol level got cleaner, but the critical boundaries now depend on how each developer implements them, and most servers are small open source projects. Know whose code you run. Pin your versions.

Indirect prompt injection

Unchanged, situational

The attack needs sensitive data, the ability to act, and untrusted outside content, all three in one place. Remove one leg and it has nothing to stand on. Same as Part 1.

One risk improved, one helped at the edges, two untouched. The two untouched ones are the two that live inside your walls, which is exactly why the readiness check below exists.

Enterprise Managed Authorization, one badge for the whole building

Until now, if twenty planners wanted the agent, that meant twenty separate setups and twenty conversations with IT. Most rollouts stalled right there.

With Enterprise Managed Authorization, IT approves the MCP server once, in the company identity system, something like Okta or Microsoft Entra, the same sign in behind your email. After that, every approved person connects with the login they already use every morning. Okta supports it. Claude and VS Code support it. Atlassian, Figma, Linear, and Asana are adopting it. This is becoming the normal way companies approve AI connections.

For a finance team it gives two things: rollout stops being painful, and you get one clean record of who connected to what. Auditors will like that.

And one limit: it controls who may connect. It says nothing about what each person can see inside EPM once they are in. That is still your dimension security, your access groups, your approval units. Approvals just got easier, so access design just got more important. If your EPM security is loose today, easier connections make that problem bigger, not smaller.

The worst version is the shared shortcut: one stored account, sometimes with admin access, wired in behind a team server. Every person who talks to that server inherits that account's power. The planner who should only see the Canadian entity sees everything. An agent is only as safe as the login it runs under.

The ten question readiness check

You do not need a single technical skill to run this check. You need one hour and honest answers. Check off each question you can answer with confidence. Your progress saves in this browser, so you can come back to it.

AI Agent Readiness Check

0 of 10 answered with confidence

Check a question when you can answer it confidently for your environment. Progress saves in your browser only. Nothing is sent anywhere.

Identity
Access
Connections
Audit
Start checking to see where you stand.
Each question you can answer with confidence is one less unknown between you and a safe rollout.

The audit trail, in three questions

Every agent action in a finance system should be able to answer three questions. Who asked. What ran. What did it touch.

The new enterprise login gives you the first layer: who connected. Oracle EPM gives you the last layer: what changed inside the application. The layer in between, tying a specific request to a specific action, is where most setups have a gap today. Closing that gap properly, with your systems and your close process, is design work. But once you know the three questions, you know what to ask for.

The question to ask before rollout: where does the data go?

Your user security can be perfect. The enterprise approval can be perfect. Every answer above can be yes. One question is still open: when the agent reads your data, where does the reading happen?

The agent does not read your reports inside EPM. It hands them to the AI tool behind it, and that tool runs on servers that belong to someone. Ask plainly: which company reads our pages, in which country, and what do they keep? If nobody in the room can answer, that is a finding.

With the open source server from the April series, the pages are read by the AI tool you connect to it. For one user, on their own laptop, with their own credentials and a policy their company accepted, that can be a reasonable, understood trade, and many teams run exactly that today, on purpose. But for a finance team at scale, many organizations will answer: our numbers do not leave our walls. That is a fair answer.

There is a design for that answer: the AI runs inside your own environment, on infrastructure your company controls, so the data never has to leave. Setting that up, with your systems, your security model, and your vendor agreements, is design work, and that is the work I do with clients. If this question matters to your team, a discovery call is the fastest way to talk it through.

Where this leaves us

The specification is final. The connection layer is stronger than it has ever been. And the responsibility for what an agent may see and do sits exactly where it always sat: with your security design. The teams that get this right will not be the ones with the cleverest agents. They will be the ones with the clearest answers to the questions above, including the one to ask before any rollout: where are the pages read.

Resources

Frequently Asked Questions

Does the final MCP specification make my AI agent secure?
It makes connecting more secure: stronger OAuth alignment, tokens bound to the server that issued them, and an enterprise approval path. It does not decide what the agent can see or do once connected. Microsoft's own security guidance states that the protocol deliberately does not enforce security for you. What an agent can access inside Oracle EPM is governed by your EPM security design.
What is Enterprise Managed Authorization and does it replace EPM security?
Enterprise Managed Authorization, stable since June 2026, lets IT approve an MCP server once in the company identity system, such as Okta or Microsoft Entra, so every approved user connects with their existing company login. It controls who may connect and gives one clean audit record of connections. It does not replace EPM security: what each person can see and do inside Oracle EPM is still decided by your dimension security, access groups, and approval units.
Can an AI agent bypass Oracle EPM security?
Not on its own. An agent holds no special powers: it acts with the access of the login it runs under. The bypass happens when a shared server is wired to one stored account with broad access, because then every user inherits that account's visibility and per person EPM security no longer applies. If each person connects as themselves, EPM security keeps working exactly as designed.
What is a shadow MCP server?
A shadow MCP server is one connected to company systems without registration or governance, a term used in Microsoft's 2026 state of MCP security report. They usually start as well intentioned experiments on someone's laptop. The risk is that nobody governs what they can reach, so the first step of any readiness check is an inventory of every MCP server connected to your environment today.
What should a finance team check before scaling AI agents on planning data?
Ten questions in four groups. Identity: who does the agent run as, would you give a new hire that access, who approved it. Access: can the agent see anything the asking person cannot, can it reach workforce or unreleased data. Connections: do you know every connected MCP server, does your identity provider support enterprise approval, is the code source known with pinned versions. Audit: can you trace who asked, what ran, and what it touched, and who owns the response when something unexpected happens.
Where does my data go when an AI agent reads it?
The agent passes your request and the relevant data to the AI tool behind it, and that tool processes the data on its own servers. Which company runs those servers, in which country, and what is retained depends on the AI tool and the agreement your organization has with that vendor. Before scaling, ask three things: which company reads the data, where it is processed, and what is kept. For organizations that require data to stay inside their own environment, the design answer is to run the AI on infrastructure the company controls, so the data is read inside the enterprise environment. Setting that up correctly is design work that depends on your systems, your security model, and your vendor agreements.
Did the NSA really publish security guidance about MCP?
Yes. In May 2026 the NSA's Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled Security Design Considerations for AI-Driven Automation Leveraging the Model Context Protocol. Its core message is that traditional controls like authentication and input validation are necessary but not sufficient, and that agentic systems need security designed as a whole rather than patched in pieces.

The readiness checks in this guide come from AI security work I do with finance teams.

Fred Mamadjanov is an Oracle ACE Pro and EPM Solution Architect based in Toronto. He runs FMEPM, a consulting practice for Oracle EPM, NetSuite Planning and Budgeting, and Vena Solutions.