Microsoft Project Perception, Token and Proof: Securing AI Agent Approval and Authority

For enterprise IT teams, these developments address different parts of the same problem. Who owns the agent? What may it do? Which actions need human approval? And what evidence remains when somebody asks, “Who authorized that?”

Microsoft puts boundaries around the agentic insider​

Microsoft’s October 19 announcement extends Project Perception to agents operating inside organizations. Its central principle is that security authority must sit outside the model: an agent should not control the mechanisms meant to constrain it. Microsoft also says Perception and Microsoft Agent 365 share signals, context, and a unified registry.

The company is adding discovery for 35 local agent types, bringing its stated coverage to 60, including GitHub Copilot, Claude Code, and OpenAI Codex. It is also extending Microsoft Entra Agent ID to additional agent patterns, including previously unknown agents found through security sensors. Discovery, however, should not be confused with automatic enforcement.

Microsoft describes three connected controls:

• Dynamic Agent Risk: continuously reassesses activity and security context.
• Dynamic Conditional Access: can narrow permissions, preserve reads while blocking writes, require human approval, or stop execution.
• Guardian Agents and playbooks: investigate and coordinate responses within human-defined boundaries.

For administrators, the architectural message is straightforward: give the employee and the agent separate authority, then constrain the agent’s task rather than handing it the employee’s entire key ring. Microsoft describes task-scoped, time-limited permissions—not unrestricted delegation.

Token adds a fingerprint checkpoint​

Token’s TokenCore Card, unveiled at Authenticate U.S. 2026, combines on-device fingerprint verification with FIDO2 passwordless authentication. According to Token’s announcement, it also supports Bluetooth and NFC and is designed to work alongside existing identity and access management, single sign-on, and privileged access management infrastructure. The company says biometric information remains on the device while signed authentication evidence leaves it.

Token reports setup taking under five minutes and logins under two seconds. Those are vendor figures, not independent benchmarks. The card extends the agent-approval capability Token introduced in June: consequential operations, such as releasing a transfer or changing access rights, can wait for an authorized person’s fingerprint approval.

The useful distinction is between authenticating a person and authorizing an operation. A fingerprint checkpoint can establish human involvement, but an evaluation should also examine exactly what the person sees and approves. “Approve this agent” is a very different proposition from “approve this recipient, amount, and account.”

Proof binds approval to transaction terms​

Proof announced production capabilities for its x401 protocol on October 15. Its offering includes an agent identity wallet and a Model Context Protocol server; the company claims compatibility with assistants including Meta’s Muse, ChatGPT, Grok, and Claude. Its assertion that it is first to deliver this combination in production remains a vendor claim.

In Proof’s described workflow:

1. A website requests identity evidence and, where needed, signed transaction terms.
2. The person reviews the request on their device and authenticates biometrically.
3. A hardware-protected key signs the approved presentation.
4. The receiving business verifies the credential, signature, and terms.

Proof says changing a signed amount, recipient, or other term invalidates verification. It positions x401 as identity and authorization infrastructure alongside x402 payments, rather than as a replacement for payment processing.

Proof first published x401 in June and identifies September’s Superfluid Wallet launch as an early production implementation. It is demonstrating the end-to-end experience at Money20/20.

This supports a practical procurement question: can the receiving organization verify the precise approved action, rather than merely trust the agent’s claim that somebody said yes?

World ID and Transmit broaden the picture​

World’s announcement adds another approach. World ID for banking and finance combines cryptographic proofs concerning human identity, presence, and attributes for internal and customer-facing financial workflows. Its AgentKit developer tools, described as beta, allow people to delegate certain proofs to agents so those agents can demonstrate a connection to a real human. These are World’s stated capabilities, not independent evidence that every financial authorization requirement is satisfied.

Meanwhile, Transmit Security appointed Matt Thompson CEO on October 19. Thompson previously served as Socure’s president and chief commercial officer. The Boston Business Journal reports that his appointment accompanies the company’s increasing focus on authenticating and supporting AI-agent activity. Leadership experience is relevant market context, but not a technical security benchmark.

The regulatory context also needs careful boundaries. FinCEN’s related announcement concerns verifiable digital credentials under the Customer Identification Program rule. That subject should not be mistaken for a blanket regulatory endorsement of an agent-authorization product.

What IT teams should ask before deployment​

These announcements suggest complementary control points, not one interchangeable solution. Microsoft addresses enterprise visibility and containment; Token supplies a human checkpoint; Proof describes transaction-specific evidence; World focuses on proofs that can accompany human and delegated interactions. No broad interoperability between them is established by these announcements.

For a pilot, security teams should ask vendors to demonstrate:

• A distinct agent identity with a named owner.
• Permissions limited to the task and its duration.
• Approval screens showing the actual consequential action.
• Rejection when approved transaction details change.
• Revocation and containment when risk rises.
• Audit evidence distinguishing human approval from agent execution.
• Exact availability, integration requirements, and deployment limitations.

The bottom line is not that every agent needs a fingerprint reader. It is that access, human presence, delegated authority, and transaction consent are separate questions. A credible deployment should answer each one—before the agent gets anywhere near the corporate credit card.