What Is Pay Per Identity Action™? Outcome-Based Identity, Explained

Pay Per Identity Action™ is Avatier's pricing model for identity management in which customers pay only for completed, verified, policy-compliant identity outcomes, not for user licenses, software modules, or professional-services hours. Avatier calls those outcomes Secure Outcomes: a password reset that finished, an account unlock that went through, an identity verification that passed, an access approval that was granted under policy, a lifecycle change that executed. Each one is recorded with its own evidence, and each one is the billable unit.

That is the whole idea, and it is a bigger change than it sounds. For roughly three decades, enterprise identity has been bought as capacity. You licensed every identity in scope, bought the modules you expected to need, and funded an implementation project before the system did any real work. The buyer carried the risk that the software would deliver. Avatier founder and CEO Nelson Cicchitto describes the shift as changing "the unit of value from software ownership to verified identity work."

This piece is the reference definition: the billable unit, how it differs from traditional licensing, why the audit record matters, how the Model Context Protocol makes it workable, who it fits, and where it falls short. It is the hub for the MCP Actions pillar of the Identity Anywhere 2027 series. The companion pieces go deeper on MCP identity governance, the Avatier Ledger audit trail for AI agents, how to secure MCP servers, and what agentic identity is.

What counts as a billable identity action

A billable identity action is a Secure Outcome. Avatier defines Secure Outcomes as completed, verified, policy-compliant activities, and its published examples are authentication, password resets, account unlocks, identity verification, access approvals, policy enforcement, and lifecycle changes.

Three qualifiers carry the weight in that definition.

Completed means the work finished. An abandoned reset flow is not a reset. The model charges for results, not attempts or feature availability.

Verified means the system established who was asking and that they were entitled to ask. Paying for unverified actions would mean paying for exactly what attackers exploit at the help desk.

Policy-compliant means the action ran through the customer's existing policies, approvals, and roles. Nothing bypasses governance. In Avatier's framing, the AI assistant a person talks to is the interface, never the authority.

In Avatier's product, those outcomes are delivered through Avatier Actions, an MCP connector that exposes more than 50 identity outcomes as MCP tools across eight modules:

1. Password Management: unlock, forgot password, change password, enrollment, account and activity views, account linking.
2. Help Desk: assisted unlock, quick and full assisted reset, batch reset, verify user, enrollment email, activity, mapping, and un-enrollment.
3. Lifecycle Management: request and remove access and roles, workflow participation, rehire, and transfer.
4. User Management: enable, disable, delete, rename, profile and direct-report updates, organizational-unit moves, account expiration, and proxy of authority.
5. Group Management: actions spanning membership, ownership, nesting, and expiration.
6. Access Governance: campaign management and review.
7. Workflow Approval: pending requests and history.
8. Reports: identity reporting, answered as questions rather than exports.

The list makes the billable unit concrete. An assisted reset for a locked-out nurse is one outcome. A manager approving a pending access request in Microsoft Teams is one outcome. A termination executed by asking, with the audit evidence produced at the end, is lifecycle work with a defined end state. What is not on the list matters just as much. A seat that exists, a module that sits installed, a console someone logs into, and a consultant hour are not outcomes, so under this model they are not what you pay for.

For the reset-heavy end of that list, the underlying workflows are the same ones Avatier's Password Portal and Assisted Reset pillars cover. Pay Per Identity Action changes how that work is bought, not what good reset governance looks like.

How it differs from per-user, per-module, and services licensing

Most enterprise identity budgets stack three traditional patterns: per-user licensing for every identity in scope, per-module licensing for each capability, and services-led pricing for implementation and consulting. Each puts most of the delivery risk on the buyer, because money is committed before anyone knows how much identity work the system will perform.

Pay Per Identity Action moves the unit of charge to the other end of the process. The comparison below is conceptual. It is about who carries which risk and what the bill can prove, not about price points.

Dimension	Per-user licensing	Per-module licensing	Services-led licensing	Pay Per Identity Action™
Unit of charge	Every identity in scope	Each capability purchased	Project scope and consulting hours	Each completed, verified, policy-compliant outcome
When the buyer pays	In advance, for the term	In advance, per module	Before and during rollout	After an outcome completes
Who carries delivery risk	Buyer	Buyer	Buyer	Shared, weighted toward the vendor
Dormant or unused capacity	Paid for anyway	Paid for anyway	Sunk cost	Not billed as outcomes
What the invoice can prove	Headcount in scope	Features owned	Effort spent	Work completed, with a record per charge
Budget predictability	High	High	Variable with scope changes	Tracks volume, so it varies with activity
Main buyer discipline	Keeping scope accurate	Avoiding shelfware	Controlling scope creep	Defining outcomes and forecasting volume

The row that tends to surprise finance teams is the fifth one. Under seat or module licensing, an invoice proves that you owned something. Under an outcome model, each charge corresponds to a piece of work that finished, and in Avatier's implementation each of those outcomes carries its own audit record. That is why a CFO briefing in Avatier Ledger can reconcile identity spend to completed actions.

If you want the traditional cost structure in more depth first, the login reset licensing models reference walks through per-user, per-event, and modular reset pricing, and the hidden costs of identity management covers the line items that rarely appear in a seat quote.

License models charge for capacity before anything runs. Pay Per Identity Action™ charges for completed work, and each charge carries its record.

Why the audit record is part of the product

An outcome-based price only works if both sides can agree on what happened. Without a verifiable record, the model collapses into trust-me billing. The evidence is what makes the pricing honest.

Avatier states that each Secure Outcome records six things:

1. The identity involved: whose account, access, or credential was acted on.
2. The initiating agent or experience: whether a person in Teams, a help-desk technician, an AI assistant, or an autonomous agent started it.
3. The authorization context: the authority under which the request was made, including delegated authority.
4. The policy applied: which rule allowed, shaped, or blocked the action.
5. The action taken: what actually ran.
6. The final result: the end state.

Six fields travel with every Secure Outcome: who, what started it, under what authority, which policy, what ran, and how it ended.

Avatier Ledger, the second MCP connector in the release, is where that record becomes useful. Ledger turns every outcome into evidence and every report into a question. It records who asked, what ran, under whose authority, and what policy allowed it, for human-initiated and agent-assisted actions alike. Through Persona Briefings, it then answers the same underlying evidence differently for different readers. A CISO receives applicable compliance frameworks blended with the organization's identity and password statistics, with remediation grouped into 0 to 30, 30 to 90, and 90-plus day windows. A CFO receives cost and breach prevention, with identity spend reconciled to completed actions. The security team receives exposure, dormant and orphaned access, privileged activity, and the vishing surface at the help desk.

That design choice matters for two reasons beyond billing. First, auditors have moved past asking whether MFA is turned on. Avatier CISO Dr. Sam Wertheim put it in terms of which human or AI identity touched a regulated system, what authority it used, what policy was enforced, and where the evidence is. A record written at the moment of execution answers those questions without a reconstruction project. The access review an auditor actually wants is built on exactly this kind of evidence.

Second, AI agents change the stakes. When an assistant acts on a person's behalf, that action is an identity event, and an organization that cannot audit an AI-initiated identity action does not fully control it. The Avatier Ledger audit trail deep dive covers the evidence schema in detail. For this definition, the point is simpler: under Pay Per Identity Action, every charge is an outcome that completed, and every completed outcome already carries its receipt.

How MCP makes outcome-based identity possible

The Model Context Protocol (MCP) is an open standard, originally introduced by Anthropic in November 2024, that lets AI assistants connect to tools and data through MCP servers. A server exposes tools the assistant can invoke, resources it can read, and prompts it can use. The MCP authorization specification builds on OAuth 2.1.

MCP is not what makes outcome pricing a good idea. It is what makes outcome pricing practical to run, for three reasons.

Each outcome becomes a discrete, named unit. In a traditional identity suite, a password reset is a path through screens, back-end calls, and tickets. It is hard to count cleanly and harder to audit end to end. Exposed as an MCP tool, the same reset is one named capability with defined inputs and a defined result. Something you can name and bound, you can count, govern, and bill.

Every request passes through one governed chokepoint. AI assistants connected to Avatier do not get unrestricted access. Every request must invoke an approved Avatier capability and stays subject to authentication, authorization, delegated authority, policy enforcement, and audit controls. Avatier decides whether the action is permitted and records what occurred. Because that decision point sits in the connector, the policy check and the evidence write happen in the same place, every time, whichever assistant made the request.

The interface can change without changing the unit. Avatier Actions and Avatier Ledger work inside Claude, Claude Code, Microsoft Copilot, Avabot, and any MCP-compatible assistant. An unlock requested by voice, in Teams, in Outlook, or by an agent built in Claude Code is the same outcome with the same record. That is what lets the price attach to the work rather than to the channel or the seat.

Here is an illustrative sketch of what a governed tool call and its result look like conceptually. It is not Avatier's actual API schema; field names are simplified for explanation.

{
  "tool": "request_access",
  "arguments": {
    "user": "j.alvarez",
    "application": "finance-reporting",
    "justification": "Quarter-close support"
  },
  "result": {
    "status": "pending_approval",
    "policy_applied": "finance-apps-manager-approval",
    "initiated_by": "assistant on behalf of j.alvarez",
    "evidence_id": "recorded"
  }
}

The assistant asked; the connector checked policy, routed the request for approval, and recorded the context. The approver's decision then becomes its own recorded step.

One flow produces the outcome, the evidence, and the briefing, so billing, audit, and reporting all read from the same record.

MCP also brings its own security obligations: least privilege, scoped tokens, allow-listing, human approval for sensitive actions, logging, awareness of prompt injection and tool poisoning, and supply-chain vetting of any server you connect. Those are covered in how to secure MCP servers and, at the governance layer, in MCP identity governance. The conversational identity hub shows how the same outcomes surface across chat, voice, and phone, and requesting access in Microsoft Teams walks through one common flow.

Who Pay Per Identity Action fits, and who it does not

Outcome-based identity is not the right commercial model for every organization. It tends to fit well in a few recognizable situations.

Organizations paying for capacity they do not use. If a large share of licensed identities are seasonal workers, contractors, or accounts that rarely generate identity work, a model that bills completed outcomes aligns spend with activity instead of headcount.

Help-desk-heavy environments. Password resets, unlocks, and identity verification are high-volume, well-defined outcomes. Avatier's credential governance customers report help-desk password ticket reductions of up to 70 percent. When the work is that repeatable, it is easy to define and count as an outcome.

Teams that want evidence with every action. CISOs preparing for audits, and CFOs who want identity spend tied to results, get the same record from the same system.

Organizations bringing AI assistants and agents into identity work. If people already work in Claude, Copilot, or Teams, and agents are starting to request access or run lifecycle steps, a model built on governed MCP tools matches how that work arrives. The agentic identity hub and the Ai4 2026 agentic AI identity security recap cover that shift.

It fits less well in other situations.

Budgets that require a fixed annual number. Some procurement-controlled organizations need one figure set a year ahead. An outcome model can be forecast, but spend moves with activity.

Environments where outcomes are hard to define. If an organization cannot yet say what a completed lifecycle change or a finished access review means in its own processes, it will struggle to agree on a billable unit. That work has to come first.

Programs that want a tool, not a service. Some teams prefer to own and operate identity software themselves. The outcome model shifts delivery accountability toward the vendor, and not every team wants that relationship.

What Avatier ships toward this pattern

Pay Per Identity Action™ is the commercial model for Avatier Identity Anywhere 2027™, the MCP-based identity platform Avatier announced at Ai4 in August 2026. Avatier Actions and Avatier Ledger, announced on September 24, 2026, are available through it. Here is what the sources confirm.

The commercial structure. Getting started is free. Deployment services are included at no additional cost. The Avatier Secure Outcome Guarantee™ means that a customer not satisfied within the first 45 days of paid service may request a refund. Pricing is based on environment size, expected usage, security requirements, and the Secure Outcomes deployed. Full commercial terms go only to qualified organizations in the invitation-only preview.

The connectors. Avatier Actions delivers the 50+ outcomes across eight modules described above, and Avatier Ledger holds the evidence and produces the Persona Briefings.

The setup. One administrator connection. Permissions are inherited from Microsoft Entra ID, Active Directory, Okta, or Ping, with no per-user setup and no new permissions model. Avatier runs alongside those platforms and alongside SailPoint, Saviynt, ServiceNow, and Moveworks.

The channels. Web, mobile, Microsoft Teams, Outlook, chat, voice, phone, APIs, and MCP-compatible AI, in 34 languages. IT teams can also build their own governed identity experiences with Claude Code, OpenAI Codex, GitHub Copilot, or any MCP client.

The proof points. A healthcare organization with more than 100,000 identities is running the platform. Avatier was founded in 1997, is based in Pleasanton, California, and has sold over 15 million licenses.

The Avatier Trust Center publishes the security posture behind all of this. Avatier is SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, and CSA STAR Level 1. It is also NIST 800-53 Rev. 5 aligned, FedRAMP-aligned, a signatory to the CISA Secure-by-Design Pledge, and FIDO2-compatible. The Ledger's evidence helps support NIST, SOX, HIPAA, and GDPR evidence needs; it does not certify you against them.

How to evaluate an outcome-based identity model

Whether you are looking at Avatier or at outcome pricing as a category, the evaluation questions are the same. Work through them before you compare anything else.

1. List your top outcomes by volume. Resets, unlocks, access requests, joiner-mover-leaver changes, access reviews. The enterprise IAM cost comparison reference is a useful frame for pulling historical volumes.
2. Write down what "completed" means for each one. For a reset, is it the new password being set or the user signing in with it? For an access request, what happens when the request is denied? Get these definitions agreed in writing.
3. Ask how policy enforcement is counted. Policy enforcement is one of the published Secure Outcome types. Understand how a blocked or denied action appears on the record and on the invoice.
4. Map the evidence to your auditors. Confirm that the six recorded fields answer the questions your internal and external auditors actually ask, in the format they use.
5. Model volume swings. Run your forecast against a hiring wave, a merger, and a forced credential rotation. Know what spend looks like in a heavy quarter, not just an average one.
6. Scope the guarantee window. Use the 45 days of paid service to test the outcomes you care about most, so the guarantee covers a meaningful trial rather than a quiet month.

What Pay Per Identity Action does not solve

It does not make spend perfectly predictable. Outcome pricing tracks activity. A reorganization, an acquisition, or a mandatory credential reset across the workforce will raise the number of outcomes in that period. You can forecast and model it, but you cannot get the fixed-number predictability of a seat license without giving up the link between spend and work.

It requires defining outcomes up front. The model is only as clear as the definitions both sides agree to. Vague definitions of "completed" or "verified" create invoice disputes. That definition work takes time from identity, security, and finance, and it has to happen before you rely on the numbers.

Its prices are not public. Pricing details are available only through the invitation-only preview, and they depend on environment size, expected usage, security requirements, and the outcomes deployed. That is normal for enterprise identity, but it means you cannot model exact cost from public information.

It does not fix bad policy. Every outcome runs through your existing policies, approvals, and roles. If those are overly permissive, the outcome will be efficiently and faithfully permissive, with an excellent record. Outcome pricing rewards clean governance. It does not create it.

It does not remove the need to secure the assistant layer. Connecting AI assistants to identity actions creates real risks, including prompt injection, tool poisoning, over-broad tokens, and unvetted servers. The connector's policy checks are one control. Least privilege, human approval for sensitive actions, and server vetting still have to be designed.

And it does not make the vendor's count self-certifying. An outcome model gives you a record for every charge. It is still your job to reconcile that record against the invoice. The value of the model is that the reconciliation is possible at all, because each billable outcome carries its own evidence.

Pay Per Identity Action™ changes the question a buyer asks from "how many seats do we need?" to "how much identity work do we need done, and can we prove it happened?" For organizations that can define their outcomes and live with spend that follows activity, that is a better question. For those that cannot yet, the definition work is where to start.