Your Integrations Run as a Shared Service Account. That Isn't Governance.

Start by giving the integration platforms their due, because the expert reader will stop reading if you don't. Prebuilt connector breadth collapses months of point-to-point wiring into days. API-led connectivity turns brittle one-off links into reusable, governed APIs the whole enterprise can consume — real acceleration, real reuse. Design-time rulesets and a single control plane over the API estate give security teams genuine leverage: consistent policy, versioning, rate limits, one view of the attack surface. And the newest layer is legitimately advanced. An agent control plane can discover your APIs, turn them into agent-ready tools, issue a delegated identity to each agent, apply guardrails to which agents and tools may be invoked, and even offer a form of guided determinism over how an agent sequences its calls.

If your problem is "we have a thousand APIs and a wave of agents about to call them," that is valuable governance and it is not marketing. But notice precisely what all of it governs: the call. Which endpoint, which agent, which token, which policy at the gateway. Everything above is edge control over the interaction. None of it is control over the business action.

The category has been unusually candid about its own ceiling. The AI-ready integration platforms concede that ungoverned tool access means an agent simply inherits your access, and that in practice most deployments run under a shared service account — which, by their own admission, erases user attribution. The business-automation platforms describe their governance as scoping what a tool or integration can do. Both statements are true. Both describe controls at the boundary, not at the action.

Here is the mechanical consequence. A recipe fires, an API-led flow executes, an agent picks a tool — and when the state transition finally lands inside the system of record, it lands as the integration's identity, not as the human or agent who invoked it. A delegated agent identity at the gateway narrows who may place the call. It does not travel into the endpoint as the authority under which the business write is committed. You can produce a flawless gateway log proving agent X called API Y with token Z, and still be unable to answer who was permitted to advance this instance of this process. The attribution dies at the connector.

The failure is not sloppiness; it is expressiveness. A per-call authorization is a statement about a request. A business control is a statement about a process. They do not translate.

• Segregation of duties. "The identity that created the invoice may not be the identity that approves its payment" is a property of the process instance, evaluated across two transitions. A token that authorizes one call has no memory of the other and no object to bind them to.
• Who may advance this instance. Permission to call an "update status" API is not permission to move order #48213 from state A to state B under this policy, at this step, given its history. RBAC on a connection cannot see the instance.
• An approval bound to a real identity. A human-in-the-loop step that the audit can tie to an accountable person — not to the service account that relayed the click — requires the approval to be a governed part of the process, not a message passing through a pipe.

It would be easy — and wrong — to say the agent-fabric vendors simply haven't shipped this yet. The limit is structural, and framing it any other way invites a roadmap slide that makes you look uninformed. Even the most sophisticated agent control plane governs the interaction: which API or agent may be called, under what delegated identity, with which guardrails, logged at the gateway. What it does not do — because it cannot, given where the work happens — is hold the business process's durable state, enforce the business action's authorization at the moment of execution, or emit a per-action business audit spanning the whole process. The process still executes inside the endpoints the fabric connects.

So governance concentrates at the edge while the process itself lives scattered across the systems being glued, or in no single system at all. There is no durable process object to attach a rule to, no transactional or compensation boundary across systems, and therefore no place to bind two transitions into a segregation-of-duties constraint. That remains true no matter how good the connectors, the rulesets, or the delegated identities become — because it follows from the location of execution, not from a missing feature.

Entroid's wedge is to move the thing being governed. In a Composable Process Fabric, the business process is the first-class runtime object with durable, governed state on one runtime, and governance is enforced inline at every transition — not stamped on the connection it happens to cross. Concretely, from the five primitives:

• Deterministic Workflows carry the process's durable state and enforce authorization inline, at each state change. Moving an instance from A to B is a governed action, evaluated in the runtime that holds the instance — not an unlogged side effect inside an endpoint.
• Per-action authorization bound to the invoking identity. Each business action is authorized against the human or agent that actually invoked it, never against a connection's shared service account. Attribution is a property of the action, so segregation of duties and "who may advance this instance" become expressible constraints rather than after-the-fact reconstructions.
• Atomic Agents with human-in-the-loop as a first-class step. An approval is a governed node in the process, tied to a real identity in the same audit as every automated transition — not a message relayed under the pipe's credentials.
• Connectors as the only primitive that touches external systems. They are the thin, typed, audited I/O edge of the process — where the fabric reads and writes the estate — not the place the business logic runs.

Be honest about the boundary: this does not abolish integration, and ES does not pretend to need zero of it. It runs over the same estate through governed Connectors. What changes is where state and authorization live. The connector becomes the audited edge; the process becomes the governed runtime object; and one immutable, per-action audit can finally answer the question the gateway log never could.

When the process is the object, the controls your auditors actually ask about stop being aspirations. Segregation of duties is a rule the runtime enforces across transitions, not a report assembled from disconnected logs. Every advance of an instance is authorized to a named human or agent. Every approval binds to a person. And when the regulator, the CISO, or the incident review asks "who moved this instance from state A to state B, and under what authority," there is a single per-action audit that answers by name — because the action was governed where it ran, not merely permitted where it passed.