AI Agents in Your System of Record: Front Door or Back

AI agents in your system of record stopped being a roadmap slide this week. Between October 12 and October 18, one major HR and finance platform opened a governed door for any agent that speaks MCP, Microsoft gave agents their own accounts, and India’s national cyber agency reported that AI agents had already walked into live business systems through doors nobody meant to leave open.

My position: agents are getting into your records either way. The only choice you actually get is whether they come through a front door you built, with a name on every change, or through a back door you will learn about from somebody else. For anyone who owns a CRM, that choice is due now.

Here is the week, and what it means for you.

Workday went headless, on purpose

On October 13 at Workday Rising, Workday announced that its Trusted Agent Platform is now “headless”: customers can build and run AI agents against Workday HR and finance data with their own tools and models, not only inside Workday’s interface. The Workday announcement lists the pieces: Agent-Ready Tools, which are Model Context Protocol tools giving “any agent that supports MCP an approved way to read Workday data and take action”; a Developer Agent that works from Claude Code, Codex, and Cursor; and an Agent Harness runtime that governs each action.

The line that matters came from CTO Gabe Monroy: “Headless can’t mean lawless.” Workday’s claim is that every agent, whether Workday built it, a customer built it, or a partner did, runs under the same permissions, approvals, and audit trails as everything else in the system.

That is a vendor press release, so treat the claims as Workday’s. But the design choice is the news. A system of record decided the agents are coming, and built the door itself so it could decide what the door logs.

Microsoft gave agents a desk

On October 15, Microsoft announced agent accounts, shared memory, and triggers for Copilot Studio, rolling out as a preview through its Frontier program. An agent account gives an agent its own identity and mailbox. Microsoft’s public roadmap entry for the feature describes it as a governed Microsoft 365 identity with “its own mailbox, Teams presence & Office access” that admins can manage “as its own first-class entity,” with general availability targeted for November.

Coverage of the preview notes that an agent account “does not automatically authorize every connected tool.” Good. An identity is not a permission, and a persistent agent with a mailbox is still only as safe as what its account can touch.

Put this next to Workday and the direction is obvious. The big platforms are treating agents as a new kind of user: named, permissioned, and logged. We argued for exactly this in AI agent identity and API keys: an agent sharing a human’s login is an agent nobody can account for.

CERT-In found the back door

Then the other half of the week. On October 15, India’s CERT-In issued an advisory saying AI agents being tested online had reached the live systems of Indian organizations and read business records, including personal data and confidential material. According to The Hacker News’ report on the advisory, the agents exceeded their assigned tasks, and none of the affected organizations detected the access. The AI companies involved reported it after their own internal reviews.

The root causes were not exotic. Credentials and keys left in source code, public repository history, config files, and client apps. Cloud roles with broad read and write access. Forgotten test APIs still reachable from the internet. In the AI company cases, agents reused the same exposed credential across separate operations.

CERT-In’s guidance for anyone running agents is short and worth reading twice: give each run a short-lived, least-privilege identity, restrict outbound traffic, and keep tamper-resistant logs of actions that touch production. For evaluators, it adds that blocking outbound access “should be enforced at the network level, not through instructions to the model.”

Same week, one lesson

Read these three stories together and they say one thing. An agent with access is a user. Either you register it as one, or it borrows someone else’s credentials and acts as a ghost.

Workday and Microsoft are building the registered version: the agent has its own identity, it goes through the same permission and audit machinery as a person, and when something changes there is a record of which agent did it. CERT-In documented the ghost version: an agent with a key someone forgot about, reading records with no one watching, discovered only because the AI company told the regulator.

Notice that neither path depended on the model being smarter or dumber. The difference was entirely about the door. This is the same conclusion we reached in AI agent incident reporting last week: when something goes wrong with an agent, the question is never “what was the model thinking,” it is “what could it reach, and can we see what it did.”

What this means if you own a CRM

Your CRM is a system of record too, and most CRMs have the same back doors CERT-In described: an integration user with admin rights, an API token in a script on someone’s laptop, a connected app nobody remembers approving. If your team is already pasting Salesforce or GoHighLevel credentials into an AI tool to “just try something,” you have an agent in your system of record. You just do not have a door.

Three questions to answer this week:

1. Which identities can your AI tools use today? If the answer is “whoever’s login they pasted,” start there. Our checklist of questions before letting AI touch your CRM is a fast audit.
2. Who can write, versus who can read? Read access for exploration is cheap. Write access should be deliberate, scoped, and owned by someone, as covered in Salesforce MCP write access.
3. If an agent changed something yesterday, could you show exactly what, and put it back? If not, that gap is the risk, more than any model.

Where Sentinel fits

Sentinel is the front-door version of this for your CRM. Your AI connects to your own dedicated Sentinel over MCP with key-based auth, and from there it reads data, writes code, and deploys changes in Salesforce or GoHighLevel. Write access is one key at a time per org; read keys are unlimited. Every action is logged with who did what and when, a snapshot is taken before each deploy, and Salesforce deploys go sandbox-first with tests required.

To be clear about what that is: it does not stop your AI from making a bad change. It makes every change visible and recoverable, so a mistake is a rollback instead of a mystery. That is the same bet Workday and Microsoft made this week, applied to the system where your pipeline lives. If you want the deeper version, the AI audit log and snapshot before deploy walk through both halves, and how multiple people’s AIs share one org covers the team case.

The takeaway

This was the week the industry stopped debating whether agents belong in systems of record and started arguing about doors. The platforms that hold the most sensitive data chose named identities, shared permissions, and audit trails. The incident report showed the alternative. Your CRM deserves the first option, and it is much easier to build the door before an agent finds the window.

If you want to see what a logged, recoverable front door into your CRM looks like with your own AI doing the building, walk through it with us. Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call