What to look for in an AI agent platform with centralized policy, RBAC and approval workflows

Nobody evaluates agent governance before they have an agent. The question arrives in a specific order. First someone connects a model to a system of record because the extraction quality is finally good enough. Then it writes a field nobody asked it to write, or it emails a customer a recap containing a commitment that was never made, or an auditor asks who approved a change and the honest answer is that a shared service account did. Only then does the search begin, and by then the buyer is no longer shopping for intelligence. They are shopping for constraint. That reversal matters, because most of the market is still selling the first thing. A system that reads calls and produces a summary is a note-taker and needs no governance, since a summary harms nobody. A system that reads calls and updates the CRM, opens the ticket and drafts the customer email is doing the work, and every one of those is a write. Governance is not a feature you bolt onto that. It is the thing that decides whether you are allowed to ship it at all.

Centralized means a single place that decides what an agent may do, which every integration consults. The failure mode is the opposite and it is extremely common: permissions configured per connector, so the Salesforce app has its own scopes, the ticket integration has its own API key, the mail connector has its own OAuth grant, and nobody can answer the question "what is this agent allowed to touch" without opening four admin panels and reconciling them by hand. Two tests separate real centralization from a settings page. First, can you answer that question from one screen, and is the answer generated from what the system enforces rather than typed in by whoever wrote the documentation. Second, when you tighten a rule, does it take effect everywhere at once, or does it take effect only where someone remembers to apply it. Policy that has to be remembered is not policy. It is a convention, and conventions decay the week the person who wrote them goes on holiday.

Role-based access control for staff answers which humans may do what. Borrowed wholesale for agents it answers the wrong question, because the interesting property of an agent is not its role but its scope and its attributability. Three differences change the design. An agent has no career, so its permissions should not grow; a human accumulates access as they move between teams, and that accretion is normal, whereas an agent whose permissions grow is a defect. An agent has no judgement about consequence, so the blast radius of a mistake is whatever you permitted, not whatever a reasonable person would have done. And an agent is frequently several agents, each doing one job, which means a shared credential across them destroys the only useful signal you have, which is which one did it. The practical shape of this is one scoped identity per agent, with a named human owner, credentials that expire rather than live forever, write permission limited to named fields and objects rather than to an object type, and inclusion in the same periodic access review that covers staff. The mechanics of that are in scoped agent identity. The test is blunt: disable one agent and see whether a person loses access. If they do, you have a shared account wearing a costume.

Most teams draw the approval line at importance, and it is the wrong axis. Importance is subjective, it varies by account, and it produces a queue that everyone argues about. Reversibility is a property of the action itself. A CRM field you can set back, an internal task you can close, a draft you can delete: those are reversible, and routing them to a human buys you nothing but delay. An email that has left the building, a ticket in the customer's own instance, a status change the customer can see: those cannot be unsent, and they are where the gate belongs. Getting that distinction right is what keeps the queue short, and queue length is the whole game. An approval gate is friction. Friction is exactly why approval queues get rubber-stamped by week three: if everything routes to a human, nothing is really reviewed, and you have bought the appearance of control at the price of the thing itself. Automate the reversible majority so the queue stays short enough that people still read it. The argument in full is in approval-gated vs automatic actions, and where the human sits relative to the loop is in human in the loop vs on the loop vs in command.

Policy and roles are claims about what should happen. An audit trail is the record of what did. Without it the first two are unfalsifiable, which is why OWASP lists Excessive Agency among its top risks for LLM applications and why logging alone does not address it: a log tells you what happened, it does not constrain what can happen, and a system with perfect logs and no gate is a system that will faithfully record the damage. Two records, not one. What was proposed, and what actually landed. Teams routinely keep the second and skip the first, and the gap between them is the most useful number in the system, because it is the only direct measure of how good the extraction is. If ninety of a hundred proposals are approved unchanged, the model is earning its place. If forty are edited before they land, you have a review burden disguised as automation. You cannot compute that ratio from execution logs alone. The fields worth keeping, and the reason each is there, are in the AI agent audit trail.

One. Show me every permission this agent holds, from one screen, generated from what you enforce. Two. Does each agent have its own identity, and what happens to a person's access when I disable one. Three. Is write permission scoped to named fields and objects, or to an object type. Four. What is your rule for which actions need approval, and is it reversibility or importance. Five. Do you record what was proposed separately from what landed, and can I see the ratio. Six. Can a non-engineer stop it, without filing a ticket. Seven. When a write fails silently downstream, because a validation rule or a required field swallowed it, do you detect that, or does your log say success. The seventh is the one that separates demos from production. A tool call that returns success proves the request was dispatched, not that the write landed. Field-level validation, a workflow rule, a permission nobody remembers, a required field on the target object: any of those can swallow an update while every log in the chain still reads fine. Reading the target system back and comparing the new state to the intended one is the only way to know, and most systems do not do it.

Mindlyft builds this layer as Service as a Software, which means we engineer it inside the systems a team already pays for rather than asking them to adopt another platform. Each agent runs under its own scoped identity rather than a shared credential. Writes are limited to named fields and objects. Anything irreversible or customer-facing passes an approval gate before it lands, approvals route to Slack or to a review console, and every write is reversible and leaves a receipt recording who approved what. We are live on HubSpot with a Salesforce app in production, and execution reaches Jira, Gmail and Slack. What we are not: a model vendor, a note-taker, or a platform you log into instead of your CRM. If the question that brought you here was which ones are worth it, the honest answer is that the governance questions above are worth asking of anyone, including us, and a vendor who cannot answer the seventh one is selling you a dashboard.