An embedded AI agent reads specific fields, in specific tables, through a specific set of permissions. All three major vendors document this. SAP (“What is Joule” guide): user questions to Joule are “processed in the scope of that user's identity and permissions,” restricted by the same permission checks as the application itself. Microsoft: Copilot “only surfaces organizational data to which individual users have at least view permissions” (Microsoft Learn), and Dynamics 365 Copilot responses “are based only on data that you personally can access” (D365 security FAQ). Oracle: Fusion Agentic Applications operate “entirely inside the existing Oracle Fusion Applications security framework,” with role-based access and approval frameworks (Oracle, March 2026).
Which means agent behaviour in your system is checkable before activation, not just discoverable after it. Run the six checks below per candidate process, cheapest first — roughly two days of combined effort.
Check 1 — Permissions and agent identity
Effort: half a day, most of it other people's calendars · You need: two key users with different roles, plus your platform admin.
Why it decides outcomes. Assistants answer within the permissions of the person asking. Two users can run the identical prompt and get different answers, both technically right. Unexplained, that gets filed as “the AI is unreliable.”
How. Pick the three prompts that matter most for the process. Both users run all three on the same day; put the six answers side by side. Then one written question to your admin or vendor: which identity does each autonomous agent execute under, and what can that identity reach? The answer differs per vendor — Microsoft assigns agents their own Entra Agent ID (mandatory for new Copilot Studio agents since July 2026); SAP registers dedicated agent identities in SAP Cloud Identity Services, rolling out through 2026; Oracle runs agents inside the invoking user's security context, managed through the same role-based Security Console as everything else.
Pass: identical answers for identical roles, explained differences between roles, and the agent-identity answer on paper.
Check 2 — Field population, for the exact feature
Effort: half a day · You need: a functional consultant and whoever runs your queries.
Why. Agents read standard fields. Information sitting in custom fields — the Z-field added in 2017 because the standard one didn't fit — is invisible to them. “Is our master data good” is too broad to answer; “are the fields this feature reads populated, for the records in scope” is a report.
How. Pull the vendor's documentation for the specific capability you're enabling — SAP documents Joule's scenarios per product on its help portal, Microsoft's Learn pages state per Copilot feature which data it uses, Oracle's release readiness documentation does the same per agent. Extract the field list. Then measure population on the records actually in scope: suppliers with spend this year, materials with movements this year — not the all-time table.
Pass: a percentage per field for in-scope records, a floor chosen and written down per field, and a named owner for anything under it.
Check 3 — Standard-path share
Effort: an hour of analysis, an hour with the person who knows the process.
Why. Embedded agents are configured for the standard flow. Intercompany, consignment, the plant that runs its own variant — those sit outside what the agent handles. If variants are 40% of volume, the agent covers a majority of a minority.
How. Pull twelve months of the process from your own system and count what share ran the standard path end to end.
Pass: a number, written into the business case. A 60% standard-path share is a 60% ceiling on day one — better in the scoping deck than in the adoption review.
Check 4 — Document reachability
Effort: half a day of inventory.
Why. Grounding answers only from what has been indexed. Contracts on a shared drive, scans from before the DMS, content in an archive nobody connected — out of scope. The agent answers confidently from the subset it can see.
How. Per document type the use case needs, record four things: where it lives, whether it's indexed, who closes the gap, by when. On SAP, attach a number: Document Grounding is a Premium AI capability, metered at 0.005 AI Units per record on SAP’s published pricing — “ground it on all our contracts” is a budget line, not a toggle.
Pass: an indexed / not-indexed list with owners and dates, and the record count multiplied against the meter before anyone promises full coverage.
Check 5 — Organisational structure
Effort: one question in one workshop.
Why. Multiple ledgers, company codes, chart-of-accounts variants, shared-services constructions that span entities. Agent logic configured for one context, meeting an organisation that legitimately has several, produces the least trusted failure there is: the right answer for the wrong entity.
How. Ask the person who knows the landscape one question — does this process cross entities, ledgers or plants anywhere the standard configuration doesn't expect? Write the answer down.
Pass: “no”, or a list attached to the scope.
Check 6 — The decision, per process
The five checks above produce a one-page readiness answer for one process: permissions behave and are explained, field population is measured against a chosen floor, standard-path share is known, documents are reachable and budgeted, entity complexity is mapped. Make the go/no-go on that page — for the two processes you intend to activate, not for the landscape.
Sufficient beats clean. Sufficient data for two processes can be verified in weeks. Clean data as a prerequisite turns an AI activation into a multi-year data programme, with the AI decision waiting at the end of it. Fix what blocks the two processes, activate, and let the results set the bar for the next two. That is also the workable reading of clean core: a constraint you clear per use case, not a state you complete first.
Per platform
SAP
Joule scenarios are documented per product on the SAP Help Portal — the field-list source for check 2. Document Grounding is Premium AI at 0.005 AI Units per record (check 4). Agent identities land in SAP Cloud Identity Services through 2026 (check 1). Module guides: FI/CO · MM · IBP · full SAP guide.
Microsoft
Learn pages state per Copilot feature which data it uses (check 2). Copilot answers within the user's existing permissions in Microsoft 365 and Dynamics 365 (check 1); autonomous agents carry their own Entra Agent ID since July 2026. Module guides: D365 Finance · D365 SCM · full Microsoft guide.
Oracle
Release readiness documentation names the objects per agent (check 2). Agents operate inside the existing Fusion security framework with role-based access via the Security Console (check 1); usage is metered in Fusion AI Units since release 26C. Module guides: Finance · SCM · full Oracle guide.
Scope note
These six checks are not survey findings. Each maps to a mechanic the vendors document themselves — permission scoping, role-gated access, grounding indexes, standard-flow configuration, agent identity. That is what makes them checkable in advance. Any agent that reads your system inherits your system's gaps.
Related
The data side is half the readiness question. The organisational half — ownership, platform, decision rights — is the AI-Readiness Reality Check (eight questions, two minutes). And for what these agents cost to run, the Embedded AI Ledger documents 148 of them across six suites with who pays for each.
Sources — the vendor documents quoted on this page
- SAP: “What is Joule” guide (identity and permission scoping) · Architecture Center: Agent Identity · Business AI pricing FAQ
- Microsoft Learn: Data, privacy, and security for Microsoft 365 Copilot · FAQ for Copilot data security and privacy in Dynamics 365 · Copilot Studio agent identities (Entra Agent ID)
- Oracle: Fusion Agentic Applications announcement (24 March 2026) · docs.oracle.com: giving users access to AI agents
All quotes verified against these documents, August 2026. The six checks are a working order, not a vendor standard.