ORIGINAL FRAMEWORKS

Your Systems of Record Are Now Agent Infrastructure. Most Organizations Don't Know It Yet.

A two-tier diagnostic for regulated enterprises deploying AI agents on top of Jira, Salesforce, ServiceNow, SAP, and the Microsoft stack.

v1.0 · April 2026Sougata Roy, sougataroy.com

Free to read and cite with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of any framework, term, or model as your own.

Explore all frameworks

The problem

Why this framework exists

In a twelve-month window ending April 2026, every major enterprise system of record opened its state to AI agents. Atlassian's Rovo MCP Server reached general availability February 3, 2026. Salesforce-hosted MCP servers reached general availability April 28, 2026. ServiceNow's AI Agent Fabric, which connects third-party agents to its platform via Model Context Protocol and agent-to-agent protocols, launched April 19, 2026. SAP's MCP Gateway went live in November 2025. Workday's Agent Gateway, built on MCP and A2A protocols, was announced June 2025.

Every one of those announcements describes how agents can read and write inside these systems. None of them addresses who authorized the agent to do so, what business state transition it was sanctioned to perform, or whose name is on the record when something changes.

That gap is not a technology problem. It is an organizational design problem. And it compounds every time an enterprise adds another agent on another substrate with another permission model.

The scenario

The permission model allowed it. That is not the same answer.

Picture the situation plainly. Your organization deploys a procurement agent that has been tested, approved by IT, and granted the correct technical permissions inside SAP. Six weeks later, a vendor gets flagged incorrectly in a risk workflow because the agent updated a status field that a human would have recognized as a compliance hold. The action was technically permitted. It was not organizationally authorized. The audit log shows the agent ran. It does not show who sanctioned that specific state transition or whether any human reviewed the business condition before the write occurred. When a regulator asks who approved the action, the answer is: the permission model allowed it. That is not the same answer.

The framework

The Agent Substrate Readiness Model

The Agent Substrate Readiness Model separates two questions that enterprise AI governance has been treating as one.

The first question is structural: does this system of record have the technical properties agents need to operate reliably? Durable state outside any single conversation. Defined ownership fields. A state machine with legal transitions. Queryable audit history. A permission model with enforcement.

The second question is organizational: has your enterprise actually authorized agents to use those properties? Not configured them. Not connected them. Authorized them, with a named sponsor, a defined scope, an approval condition for consequential writes, and a clear answer to the question of who is accountable when the agent acts.

Most enterprise AI deployments in 2025 and 2026 can answer the first question. Almost none can fully answer the second.

Tier 1

Structural Readiness

Each question has two possible answers. The system either has the property or it does not. There is no partial credit for "we're working on it."

Records or content?

Does this system store durable, identifiable records that persist outside any single session? A Jira issue, a Salesforce opportunity, a ServiceNow incident, an SAP purchase order. These are records. A Slack thread, an email chain, a shared document. These are content. Agents can read content, but they cannot reliably act on it without inventing structure that was never formalized.

State machine or labels?

Does the system enforce legal state transitions, or does it allow any label at any time? An issue that moves from Open to In Progress to In Review to Closed under defined conditions is a state machine. A tag that anyone can apply or remove at will is a label. Agents need the former to know what they are allowed to do next.

Explicit ownership or inferred?

Is ownership a field with a named value, or is it something the team figures out from conversation? An assignee field with a current value is ownership. "Whoever last touched it" is inference. Agents cannot act on inference.

Structural verbs or conversational ones?

Does the system define actions with formal semantics? Create, assign, resolve, close, escalate, block, approve. Or does it only have reply, forward, comment, and share? Structural verbs are what give an agent a grammar to work with.

Queryable history or visible-only?

Can the audit trail be searched, filtered, exported, and used as evidence? Or can it only be seen in a UI? An agent that cannot produce a reconstructable history of its actions is not auditable. A system whose history cannot be queried is not audit-ready.

Systems that score five of five on this tier are structural substrates. Systems that score fewer than three need either a structural layer added on top or they should not be in the agent's operating scope.

Tier 2

Substrate Authorization Readiness

Structural readiness tells you whether a system can support agents technically. Substrate authorization readiness tells you whether the system can enforce governed agent action, not just permit it.

Does this substrate distinguish agent identity from human identity in its own audit trail?

Jira, Salesforce, ServiceNow, and SAP each log actions differently. The question is whether this specific system can attribute a write to a non-human actor and distinguish it clearly from the human who invoked it. An audit log that says "modified by integration user" tells you nothing about which agent ran, under whose authorization, or what business condition triggered the action.

Does this substrate support operation-level authorization, or only resource-level access grants?

Most enterprise systems grant access to objects, tables, or endpoints. That is resource-level control. The governance question is whether this substrate can express something narrower: this agent may change status from Open to Closed only under these defined business conditions, and any other transition requires human review.

Does this substrate's audit trail capture enough to reconstruct the full business state at the time of a write?

Most enterprise systems log what changed and when. Fewer log what the record state was immediately before the change, what condition triggered the agent action, and whether any human approval was part of the workflow.

Does this substrate have a formally defined remediation path for incorrect agent writes?

A misclassified incident in ServiceNow is an edit. A posted payment in SAP is an accounting event with downstream journal entries. A closed deal in Salesforce may have triggered commission calculations and revenue recognition. The question is whether the substrate's own data model and process design supports clean remediation of an incorrect agent action.

Does this substrate's MCP or API exposure preserve its internal access controls, or create a bypass path?

The question for each substrate is whether its external interface enforces the same access model the UI enforces, or whether MCP or API exposure creates an access path the substrate's own permission model would not have permitted through the UI.

These are questions about the substrate itself, not about what your organization has decided. What your organization must decide about each agent before deployment is covered by the Organizational Agent Controls framework, which is the companion to this one.

Cross-platform risk surface

One agent. Five compounding governance problems.

When one agent operates across Jira, Salesforce, ServiceNow, and SAP simultaneously, the enterprise does not have four governance problems. It has five compounding ones.

Entitlement drift

Each system can enforce least-privilege access within its own boundary. No system reasons over the combined business privilege that results when an agent can read in one, infer in a second, and write in a third.

Attribution drift

One substrate may log the agent identity. A second may log the integration user. A third may log the service principal that granted the role. The action was one. The audit trail is three separate stories.

Segregation-of-duties drift

Each platform enforces its own SoD rules. None of them natively enforces SoD across a business process that spans all four.

Audit fragmentation

Each substrate can tell part of the story of what the agent did. None can alone reconstruct the full justification chain from human intent to business state transition to record change.

Rollback asymmetry

Undoing an incorrect agent action is simple in some systems and consequential in others. A misclassified incident in ServiceNow is an edit. A posted payment in SAP is an accounting event.

A CISO who cannot answer "who authorized that state change, and what was the business condition that made it valid" across all five of these dimensions should not treat the authorization problem as a future-state concern.

The Microsoft coverage gap

Identity and interaction auditability are not authorization completeness.

Microsoft Entra Agent ID is the most complete agent identity platform currently available in the enterprise market. It provides immutable object identities, sponsorship models, Conditional Access, lifecycle governance, and risk signals for agents built on Microsoft platforms.

What it does not cover is documented in Microsoft's own materials. Entra Agent ID governs agents created inside Microsoft Foundry, Copilot Studio, Security Copilot, and Microsoft 365 Copilot, and third-party agents that integrate via the Agent Identity platform. There is no Microsoft documentation claiming that Entra Agent ID governs tool-level authorization inside Salesforce, ServiceNow, SAP, or Workday once the agent is through the door.

Purview addresses interaction auditability, not authorization completeness. The question "did the agent log this interaction" and the question "was this action sanctioned by a named business decision" are different questions, and Purview answers only the first.

After both Entra Agent ID and Purview are deployed in a regulated enterprise, the hardest governance questions remain open: who approved the write, not just the prompt. What policy evaluated the state transition, not just the token request. Whether a downstream record change violated a business control, not just whether the interaction happened.

That is the gap the Agent Substrate Readiness Model is designed to surface before it becomes a finding.

Research basis

Primary sources, verified March to May 2026.

This framework draws on primary sources from Atlassian, Salesforce, ServiceNow, SAP, Workday, Microsoft, IETF, OWASP, NIST NCCoE, Cloud Security Alliance, FINRA, NSA, CISA, and FBI publications verified between March and May 2026.

Read the research brief

The Agent Authorization Layer: Why Every System of Record Is Now a Governance Surface