At TDX 2026 Salesforce called it Headless 360: every capability in the platform exposed as an API, an MCP tool, or a CLI command. A few weeks later, on 1 May 2026, Microsoft Entra Agent ID moved to general availability, introducing a three-tier identity model for AI agents that act inside enterprise tenants. Both vendors are pointing at the same future. CRM stops being a destination application and becomes a set of callable surfaces that human users, integration platforms, and increasingly AI agents reach through.
That shift looks like a developer story. It is really a governance story. When every record, every flow, every action is reachable by API or by an agent, the security model you inherited from twenty years of UI-led CRM does not automatically follow you across. It erodes by default, quietly, and the place you notice is in audit logs that can no longer answer the question of who did what and why.
What happens to governance when every object becomes an API?
In a UI-led world, governance had a backstop. Even if your permission sets were sloppy, the screen itself filtered what most users could see and change. Page layouts hid fields. Validation rules blocked inputs. Apex triggers ran inside a session that traced back to a named human. The interface acted as the last line of defence.
Headless removes that line. The same record that a sales executive can only edit through a guided path on a mobile app is now reachable directly by anyone or anything with a valid token and the right scope. Most of the controls you trusted were carried by the interface, not by the platform. When the interface is gone, those controls are gone with it.
What is CRM technical debt? It is the accumulated set of customisations, workarounds, and undocumented dependencies that make a CRM platform slower and riskier to change over time. Headless 360 surfaces a particular variant: governance debt. Permission sets that were never tight enough, profiles that were inherited rather than designed, OAuth grants given to a vendor pilot three years ago and never reviewed. None of that mattered when the UI was the only door. All of it matters when every door is open.
The honest reading of headless is not that it weakens security. It is that it exposes how much of your security was implicit. The control you thought you had was a side effect of users only having one way in.
What is agent identity, and why does headless 360 need it?
In a headless platform, the caller might be a person, an integration, or an agent acting on behalf of a person. The platform cannot distinguish between them unless identity is modelled separately. Until recently most enterprise CRMs treated agents as just another service principal or, worse, ran them under a shared admin account.
That is changing. Microsoft Entra Agent ID, generally available since 1 May 2026, introduces a three-tier hierarchy: an Agent Blueprint that defines behaviour and policy, a Blueprint Principal that carries grants applicable to all instances, and an Agent Identity that is the actual running instance with its own object ID and audit trail. Salesforce announced Trusted Agent Identity inside its Agent Fabric, which lets agents execute actions using specific user permissions and triggers mobile approval requests for high-stakes operations such as a refund or a contract change.
The reason both vendors invested in this is simple. Without per-agent identity, you cannot run a meaningful access review. You cannot revoke a single misbehaving agent without breaking everything that shares its credentials. You cannot tell whether the agent that approved an opportunity discount was the production model or a developer’s local prototype. Headless 360 makes every object reachable. Agent identity is what makes the reach attributable.
If your roadmap involves Agentforce, Copilot, or any third-party agent reaching into your CRM, agent identity has to come first. Not as a hardening project after launch, but as the foundation that the launch sits on.
Why do permissions models break when agents do the calling?
Most CRM permissions were designed for an assumption that no longer holds: that the actor is a human user, working through a single interface, in a session that lasts minutes. Agents break all three assumptions. They act on behalf of users. They invoke many tools in sequence. They run continuously, or wake on a trigger weeks after their permissions were last reviewed.
What is shadow AI? It is the unsanctioned use of AI tools, models, or agents inside an organisation, often by individual employees or teams, outside the governance perimeter set by IT and security. Headless 360 turns shadow AI into a far more serious problem. In the old world, a marketer using an unsanctioned LLM exfiltrated content. In the new world, that same marketer can wire an agent into the CRM’s public API surface and grant it scopes that would never have survived a review.
The structural fix is to redesign permissions around agent capability, not user role. An agent that summarises opportunities does not need write access. An agent that updates close dates needs write access on a specific field, not the whole object. An agent that books a meeting on a customer’s behalf needs a tightly scoped, short-lived token, not a session inherited from its operator.
Vendors are moving in this direction. The challenge for CRM owners is that the platform supplies the mechanism, but the policy still has to be designed locally. Nobody else knows which fields are sensitive in your business, which approvals are commercial rather than legal, or which workflows can be safely delegated to an agent without human review.
How do you audit a non-human caller?
Traditional CRM audit trails were built for people. The actor is a username, the timestamp is wall-clock time, the change is a before-and-after value. That model collapses when the actor is an agent identity calling on behalf of a user, invoking three tools in sequence, each touching a different object.
Microsoft Entra’s new audit schema is instructive. It adds an agentType field to identity records, distinguishing standard service principals from agent identities, agent blueprints, and agent user accounts. A blueprintId correlates a specific agent instance back to the template it was created from. That lets a security team ask questions that were previously impossible: which agents were instantiated from this blueprint, which actions did they perform, which tenant policies applied at the moment of the action.
Salesforce’s equivalent inside Agent Fabric is the AI Gateway, which standardises token management and observability across multi-model stacks. The point is the same. Without agent-aware audit, you have logs that say a service principal updated a record, but no way to trace it back to the agent, the prompt, the user, or the policy that allowed it.
CRM leaders should not accept a roadmap that adds agent capability without adding agent-aware audit at the same time. If you cannot reconstruct who acted, on whose behalf, under which policy, you cannot defend the system to a regulator, to legal, or to a customer who asks why an action was taken.
What does consent propagation actually mean?
This is the part that gets glossed over and then bites quietly. Consent is the legal and contractual record of what a customer agreed to: that their data could be used for marketing, that an agent could act on their behalf, that a recording could be processed. In a UI-led world, consent lived next to the customer record and was checked at the point of action. In a headless world, the action might originate from an agent that has never directly read the consent flag.
Consent propagation means that whenever an agent acts on behalf of a user or a customer, the relevant consent state travels with the call. If it does not, the platform will happily process an instruction that violates a customer’s preferences, because the agent had a valid token and the scope to do the action. The token was correct. The consent was missing.
The most visible vendor response to this is mobile authorisation on high-risk actions. Salesforce’s Trusted Agent Identity prompts a human for approval before money movement or legal-sensitive changes. That is a partial answer. It puts a human in the loop where the consequences are highest. It does not solve the harder problem of agents acting on lower-stakes customer data where there is no obvious moment to ask.
The design choice is whether consent travels with the call, or whether the agent is allowed to assume it. Headless platforms that do not encode that choice explicitly will end up making it implicitly, and the implicit answer is usually that consent is checked once at the start and ignored thereafter.
What does mature agent governance look like in practice?
It looks less like a security project and more like an architectural redesign. The organisations getting this right are doing four things in parallel.
They are inventorying agent surfaces. Not just the agents they intend to deploy, but the OAuth grants, API keys, MCP server connections, and integration users that already exist. Every one of those becomes an agent attack surface once headless is switched on. How to reduce Salesforce technical debt in this environment starts with that inventory: catalogue every non-human caller currently inside the platform, classify each by purpose and last review date, and retire anything that cannot be justified.
They are designing agent identity before deployment, not after. Each agent role gets a blueprint, an explicit scope, a defined lifetime, and an audit policy. The agents that need write access are reviewed quarterly. The agents that act on behalf of customers have consent checks attached at the policy layer, not bolted on at the application layer.
They are running tabletop exercises. What does an unauthorised agent action look like in the logs. Who is paged. How is the agent identity revoked without taking down the integration that depends on it. These are the questions a regulator or a board will ask in the worst week of the year. The time to rehearse the answer is now.
Why use an independent CRM partner for this work? Because the security architects who understand identity tend to sit in the platform vendor’s safety team or in your security organisation, but the people who understand how CRM is actually used sit somewhere else. The bridging work, the part where governance policy meets real workflows, sits at the intersection. An independent partner brings that bridging perspective without the bias of a vendor selling more licences or a security firm that has never owned a quota.
The Sirocco perspective
Most of our clients adopted CRM in a world where the user interface did most of the security work. Headless 360 and the maturing of agent identity standards are now removing that backstop in plain sight, and the cost of pretending otherwise is paid in audit findings, regulatory exposure, and quietly broken trust with customers.
Our view is that this is not a security upgrade to bolt on later. It is a redesign that has to happen alongside the agent rollout, not behind it. The CRMs that will earn the trust to run agentic workflows are the ones whose owners did the inventory, modelled identity properly, made consent travel with the call, and built audit trails that work for non-human actors. The capability is real. The harder question is whether your governance is ready for what your platform can already do.
If your organisation is sizing up Headless 360 or Agent Fabric and the governance question feels under-defined, schedule a consultation and we will help you map the work.
Get in Touch
If you are weighing how Headless 360 or Agent Fabric should reshape your CRM identity, audit, and consent posture, leave your details and we will set up a working session focused on the governance redesign that has to happen alongside the agent rollout.
