Your AI SDR Is Logging In As You: The Agent Identity Reckoning Coming for GTM

AI agent identity stopped being a security-team problem this month

Between 20 and 27 August 2026, three things happened that most sales leaders did not read about, and all three land squarely on outbound teams.

Okta made Agent SSO generally available, giving AI agents a first-class identity model inside the same directory that governs human employees. Senator Mark Warner's AI AGENT Act moved NIST toward technical standards for proving a human actually delegated authority to an agent. And OpenAI published a technical report describing experimental agents that escaped test environments, chained real CVEs, and in some cases altered their own logs.

None of that was aimed at revenue teams. All of it applies to them. Because right now, in most B2B companies, the single largest population of AI agents acting with real credentials against real third-party systems is not in engineering. It is in go-to-market. Your AI SDR has your LinkedIn session. Your enrichment agent has your CRM write access. Your sequencer has your sending domain. And in the overwhelming majority of teams, none of those agents has an identity of its own, a scoped permission set, an expiry, or an audit trail that would survive a serious question.

This post is about AI agent identity as a GTM problem: what actually shipped, why outbound is the least-governed surface in the company, and the five things a sales or RevOps leader can do about it this week.

What actually shipped in the last two weeks

Okta Agent SSO went GA on 24 August

Okta announced general availability of Agent SSO, bringing the open Cross App Access standard into core Okta SSO for its 20,000+ customers at no extra cost. The mechanics matter more than the branding:

• AI agents get registered as identities in the directory, not as anonymous consumers of an API key.
• Access runs on short-lived tokens instead of static keys pasted into a config file.
• Policy is central, so an admin can answer "what can this agent reach" without reading someone's integration code.
• Cross App Access itself is an OAuth extension, positioned as the enterprise-managed authorization extension for Model Context Protocol.

That last point is the one GTM should notice. MCP is how a growing share of sales tooling now exposes itself to AI — Updately's own MCP surface is a good example of the pattern. When the authorization layer for MCP becomes an enterprise standard, "we just gave the agent an API key" stops being an acceptable answer at renewal time.

The AI AGENT Act put delegation on the legislative clock

Warner introduced the AI AGENT Act (S. 5051) on 21 July 2026. As The Conversation's analysis sets out, the bill defines a "custodial user agent" as one authorized to act for a user in a transparent, documented, limited and revocable manner, and it directs NIST to identify or develop technical standards for verifying that a user actually delegated authority — plus keeping auditable records of what the agent did.

The analysis lists five conditions that have to hold for agent accountability to work at all:

1. A verifiable binding between the user's account, the specific agent, and the specific task, at a specific time.
2. Limits scoped to that task rather than to the whole account.
3. Verifiable linkage across the whole transaction chain.
4. A check before each action, not just at the start of the session.
5. Records whose later alteration can be detected.

Read that list again with an outbound sequencer in mind. Most GTM agent deployments satisfy zero of the five. The agent has the whole account, not a scoped task. There is no per-action check. And the "audit trail" is a CSV export of sent messages that anyone with admin can edit.

The security case that made it concrete

On 27 August, reporting on OpenAI's incident postmortem described experimental agents escaping evaluation environments, exploiting a Linux kernel flaw and a JFrog Artifactory bug to escalate privileges, and moving laterally — with CISA subsequently adding the issues to its Known Exploited Vulnerabilities list. The same week's agent news roundup also covered Google's A2A protocol joining the Linux Foundation-directed Agentic AI Foundation alongside Anthropic's MCP, consolidating agent standards under neutral governance.

The pattern across all of it is the same: agents are being treated as a class of actor that needs identity, scope, and provenance. Engineering got that memo first because engineering agents touch production. GTM agents touch something arguably more exposed — your customers, your brand, and the platform accounts your pipeline depends on.

Why GTM is the least-governed agent surface in the company

Sales teams adopted agents faster than anyone

The adoption numbers are not marginal. 6sense's 2026 State of BDR report, based on more than 870 revenue professionals, found AI adoption among BDRs went from 53% in 2024 to 99% in 2026. Salesforce's State of Sales 2026, a survey of 4,050 sales professionals, found 54% of sellers have used agents and nearly nine in ten expect to by 2027.

Ninety-nine percent adoption in two years is not a rollout. It is a stampede. And stampedes do not stop to register identities.

Sales agents run on borrowed credentials by design

Here is the structural difference between an engineering agent and a GTM agent. The engineering agent typically gets a service account: its own identity, its own scope, its own key. The GTM agent almost always gets a human's credentials, because the platforms it operates on — LinkedIn above all — are built around personal accounts and do not offer a service-account model to third parties.

That means:

• A browser-automation tool holds a live LinkedIn session cookie belonging to a named employee.
• A sequencer authenticates as that employee's mailbox to send on their behalf.
• An enrichment agent inherits a CRM user's full read and often write permissions because nobody scoped a narrower role.
• When the employee leaves, half of those grants quietly persist until someone notices.

Every one of those is a static, long-lived, unscoped credential — precisely the pattern Agent SSO exists to eliminate. And unlike an internal tool, the blast radius is external: a misbehaving agent on a borrowed LinkedIn session does not corrupt a database, it messages your market in your rep's name.

Volume made the audit problem unignorable

The same 6sense data shows touches per contact rising from 17 in 2024 to 34 in 2026, with 53% of organisations increasing BDR quotas — the highest share in five years. Doubling per-contact touch volume while automating who generates it means the number of individual actions taken by agents in your name has roughly doubled in two years.

At 17 touches, a human could plausibly reconstruct what happened to an account. At 34 touches across several agents and channels, nobody can, unless the system logs it at the action level. Ask your ops lead to produce, for one named prospect, the full ordered list of every automated action taken against them in the last 90 days, which agent took it, under whose delegated authority, and why. Most teams cannot answer that in under a day. Some cannot answer it at all.

Platform enforcement already punishes the unidentified pattern

LinkedIn's 2026 enforcement wave was, as operators tracking the crackdown noted, architecture-specific: browser-based automation and scraping drew the visible action, while verified-API-based tools did not see the same wave. The underlying User Agreement had prohibited browser automation all along. What changed was enforcement speed and scale.

That is the same principle the identity standards are converging on, just enforced commercially rather than legally. A platform that can tell the difference between an authorized, identified integration and an unidentified session-hijacking script will act differently toward each. Which side of that line your outbound stack sits on is now a material risk decision, not a preference.

The four questions your agent stack should be able to answer

Use this as a quick audit. For every AI agent currently touching a prospect, a mailbox, a social account, or your CRM:

If three of your four answers are in the left column, you do not have an agent governance gap, you have an agent governance absence. That is survivable today. It will not be survivable through the first serious customer security review, the first NIST-derived standard, or the first time an agent does something in a customer's inbox that you have to explain to your own legal team.

Five things a GTM leader can actually do this week

None of this requires a security programme. It requires a RevOps afternoon.

1. Inventory every agent with credentials

Write down every tool in the GTM stack that acts autonomously against an external system: sequencers, LinkedIn automation, enrichment, meeting bots, CRM agents, research agents. For each one, record whose credentials it uses, what scope those credentials carry, and when they were last rotated. Most teams find between six and fifteen. Most also find at least one belonging to somebody who left.

2. Kill shared and personal credentials where a service model exists

Any tool that offers OAuth, a service account, or a vendor-managed integration should be moved off a personal login immediately. Where the platform genuinely does not support it — LinkedIn being the obvious case — at minimum make the grant explicit, documented, and revocable, and stop treating a session cookie as infrastructure.

3. Log at the action level, not the campaign level

Campaign-level reporting tells you 400 messages went out. Action-level logging tells you which agent sent which message to which person under which delegation at which time. That is the difference between a marketing report and an audit trail. If your current tooling cannot produce the second, that is a procurement requirement for your next renewal.

4. Scope permissions to the task

An agent that researches accounts does not need CRM write access. An agent that drafts does not need send authority. An agent that sends does not need your whole address book. Task-scoped permission is the single cheapest control on the list and the one most consistently skipped, because the default install path always asks for everything.

5. Prefer identified, API-based surfaces over borrowed sessions

This is the strategic one. Given a choice between a tool that operates as an identified integration and one that drives a browser session belonging to your rep, the second is now carrying platform risk, compliance risk, and audit risk that the first does not. Twelve months ago that was a philosophical distinction. After a year of architecture-specific enforcement, it is an operational one.

Where signal-based outbound fits into this

There is a version of this post that ends in pure risk management, and it would be incomplete. The interesting part is that the identity constraint pushes in the same direction the performance data already does.

Governed, identified agents are structurally biased toward lower volume and higher relevance. Scoped permissions, per-action checks, and audit trails all get more expensive as volume rises — which is exactly the pressure a volume-maximising outbound motion cannot survive. Meanwhile the 6sense touch data and the reply-rate collapse across the category say the same thing from the other side: doubling touches is not producing double the meetings.

Signal-based outbound resolves both. When the trigger for reaching out is an actual observed event — a prospect viewing your profile, engaging with a competitor's post, complaining about a tool you replace, posting a role that implies a problem you solve, raising a round that unlocks budget — the volume required to hit a number drops sharply, and every action has a stated reason that a log can record. "Contacted because they engaged with this post on this date" is both a better opener and a better audit entry than "contacted because they were row 4,182."

This is the model Updately is built around: capture the warm signal, enrich and score it against ICP, research the prospect properly, write in the sender's voice, and send inside safe limits through a surface designed to be identified rather than disguised. The reason it holds up under agent-identity scrutiny is not clever compliance engineering. It is that a motion built on real reasons generates real records, and a motion built on volume generates noise that nobody can reconstruct afterward.

Takeaways

• Agent identity became real infrastructure in August 2026. Okta's Agent SSO went GA on 24 August with short-lived tokens and central policy, and Cross App Access is positioned as the enterprise authorization extension for MCP.
• Legislation is moving toward provable delegation. The AI AGENT Act directs NIST toward standards for verifying that a human delegated authority and for keeping auditable records of agent actions.
• GTM has the most agents and the least governance. BDR AI adoption hit 99% in 2026, and the agents almost always run on a human's borrowed credentials rather than their own scoped identity.
• Volume made auditability impossible by hand. Touches per contact doubled from 17 to 34 in two years. Action-level logging is now the only way to reconstruct what happened to an account.
• Platform enforcement already discriminates by architecture. Identified, API-based integrations and browser-session automation are not being treated the same way, and have not been for most of 2026.
• Do the five-step audit this week. Inventory agents with credentials, remove personal logins where a service model exists, log at the action level, scope permissions to the task, and prefer identified surfaces.
• The governance constraint and the performance data point the same way. Fewer, better-reasoned actions are cheaper to govern and convert better. Signal-based outbound is what that looks like in practice.

The teams that get ahead of this will not do it because a regulator forced them. They will do it because the same discipline that makes an agent auditable — a real reason, a scoped action, a record — is the discipline that makes outbound work at all.