It’s Monday morning. A renewals rep asks Claude to draft a follow-up Task for every account with a contract ending this quarter. A couple of minutes later, a few hundred Tasks exist, each one tidy and specific.

Then someone in RevOps opens one and asks a simple question: who wrote this? The Created By field says the rep. Login History says the rep. The OAuth usage page shows the rep’s token. Every trail in the org points at a person who didn’t type a word of those Tasks.

Nothing went wrong. The agent did exactly what it was asked to do, and it stayed inside the rep’s access. The gap is that Salesforce’s identity model was built for people, so the agent had to borrow a person to get in.

That worked fine while agents were a pilot. It gets awkward once they are part of daily work, and that is where most orgs are heading now. I’ve written about Hosted MCP Servers and Headless 360 before. Those posts were about the door. This one is about the name on the badge.

Why this lands now

When agents arrive from Claude, Slack, Lightning and whatever your teams adopt next, “whoever was logged in” stops being a useful answer to “which agent did this?” Salesforce saw that coming, and Agentic Identity is the fix.

Strip the announcement down and Agentic Identity does one thing: it lets an admin register an external agent directly on the platform, so the agent gets an identity of its own. It no longer operates under the identity of the person it is helping. The admin can then give that agent a narrower permission set than the human has.

Salesforce’s own analogy in the Help article is the clearest version I’ve seen. It describes registration as “issuing the agent its own badge, rather than lending it an employee badge.” At the Dreamforce AIforce keynote, the same point came up directly: an agent may only need a subset of what a human user can do.

The setup sequence in the Help article is short. Here it is as a flow.

Step 3 is the part architects should care about most. Once the client connects with the agent’s credentials, Salesforce can classify that connection as an agent instead of a person. Everything else (attribution, scoped access, separate tracking) follows from that one change.

The vocabulary you’ll need

For most of my career, a Salesforce org had two kinds of identity. There were people, who logged in and clicked around. There were integration users, who moved data on a schedule and never had a lunch break. Agents fit neither box, so we squeezed them into the first one.

Agentic Identity adds the third box. I like this design a lot, mostly because it stops us from pretending an LLM is either a person or a cron job.

Once you have three boxes, a few good things fall out of the design almost for free.

Registration itself should take minutes per agent once the feature is live. The work that takes weeks is everything before it: knowing which agents exist, who owns them and what each one really needs. Here is the order I’m using with clients.

Keep agent permission sets in source control

Whatever the registration screen looks like at GA, the permission set you attach to the agent is ordinary metadata. I want it in Git, reviewed in a pull request, with the agent’s name in the label so nobody mistakes it for a human’s access.

METADATA · PERMISSION SET<!-- Agent_Renewal_Research.permissionset-meta.xml -->
<!-- Read-only, one job, no delete. Assigned only to the registered agent. -->
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>Agent - Renewal Research (Read Only)</label>
    <description>Registered agent identity. Owner: RevOps.</description>
    <objectPermissions>
        <object>Opportunity</object>
        <allowRead>true</allowRead>
        <allowCreate>false</allowCreate>
        <allowEdit>false</allowEdit>
        <allowDelete>false</allowDelete>
        <viewAllRecords>false</viewAllRecords>
        <modifyAllRecords>false</modifyAllRecords>
    </objectPermissions>
    <fieldPermissions>
        <field>Opportunity.Amount</field>
        <readable>true</readable>
        <editable>false</editable>
    </fieldPermissions>
</PermissionSet>

Agentic Identity doesn’t arrive alone. It lands in the middle of the Winter ’27 authentication changes, so your integration calendar for the next nine months looks busy. Put these on it.

Who has to register, and when

Where most orgs are starting from

The volume numbers explain why Salesforce built this now instead of later.

Here is what I expect over the next year. This is my read, not a roadmap.

First, agent permission sets become a standard line item in every implementation SOW. Today we scope profiles, permission sets and integration users. Next year the design document will have a fourth list: one registered identity per agent job, each with an owner.

Second, access reviews grow an agent tab. The same people who sign off on integration users every quarter will sign off on agents, and the separate traffic in Digital Wallet gives them real evidence to review instead of a guess.

Third, the teams that register early will ship agents faster. Once an agent has its own badge, security teams stop asking “what can this thing reach?” because the answer is written down. That is the conversation that usually stalls agent rollouts, and Salesforce just gave us a way to settle it.