EXPLORE THE BETA PROGRAM →
What is available today, who it is for, and how participation works.
VIEW THE PRODUCT ROADMAP →
See how TPZ expands from identity governance into decision support and governed automation.
READ OUR RESEARCH & WHITEPAPERS →
Explore technical writing and the architecture behind TPZ.
Frequently Asked Questions
ABOUT TRUST PLAYER ZERO
-
Most security programs rely on multiple systems for identity, cloud, compliance, ticketing, alerts, and other functions. Each system holds part of the story, leaving people responsible for connecting the context, coordinating decisions, and proving what happened.
TPZ is being built to reduce that operational fragmentation by creating a governed layer across the existing security environment.
-
No. Dashboards are one way teams interact with TPZ, but they are not the product itself.
TPZ is being built as an operational layer that connects security context with governance, workflows, decisions, and evidence. The interface gives different users the information they need to work within that environment.
-
No. TPZ is designed to work across the systems already operating in your environment rather than requiring a rip-and-replace approach.
IAM, GRC, SIEM, ticketing, cloud, and other security platforms continue doing the jobs they were built to do. TPZ brings context across those systems to support governed decisions, workflows, and evidence as part of one security program.
-
Identity gives TPZ a practical place to start because the problems are already visible: access reviews, inactive accounts, MFA gaps, excessive permissions, and unclear ownership. We can solve those problems first, then connect more of the security environment over time.
-
TPZ is initially focused on growing financial-services organizations that face increasing security complexity, regulatory scrutiny, and customer expectations before they have enterprise-sized security teams.
The strongest fit is a lean security or IT team that needs to understand what is happening across its tools, coordinate the work, and keep a reliable record of what happened.
THE TPZ BETA
-
The TPZ Beta focuses on identity and access governance and is built around three core capabilities: Connect & Clean, Find & Fix, and Govern & Prove.
Teams can connect a supported identity environment, organize identity and access data, surface conditions that require attention, assign ownership, review access, record decisions and reasoning, track exceptions and remediation, and verify whether issues were resolved.
TPZ also maintains basic reporting and history around identity conditions, reviews, decisions, ownership, exceptions, remediation status, and verification so teams have a clearer record of what happened and why.
-
Microsoft Entra ID and Azure are the primary supported integrations for the current Beta.
TPZ uses those connections to bring identity, role, permission, MFA, activity, and related access context into one working environment.
Additional integrations are part of TPZ’s broader product roadmap.
-
TPZ can help teams identify conditions such as:
Inactive or dormant identities
Orphaned identities
Missing MFA
Elevated or excessive access
Privileged access
High-risk identities
Access requiring review
Unclear ownership
The goal is to make it easier for teams to understand what needs attention and determine what should happen next.
-
Human-governed means people remain responsible for security decisions and changes during the Beta.
TPZ can identify issues, provide context, organize reviews, assign ownership, record decisions, track remediation, and verify outcomes, but it does not autonomously change your environment. Your team determines what should happen and remains responsible for approving and carrying out changes.
-
Beta participants work directly with TPZ as design partners.
We work with your team to connect the supported identity environment, validate how TPZ interprets your identity and access data, use the platform in real security workflows, and gather feedback on what should be improved or prioritized next.
The Beta is centered on real security work rather than passive product testing.
-
The strongest Beta partners have a real identity-governance problem they need to work through today.
That may include manual access reviews, inactive or orphaned identities, privileged or excessive access, unclear ownership, or identity decisions spread across spreadsheets, tickets, and multiple systems.
-
Onboarding depends on the size and complexity of the environment and the scope of the Beta engagement.
The initial process typically focuses on connecting the supported identity environment, confirming that TPZ is interpreting the data correctly, and identifying the first workflows the team wants to use inside the platform.
PRODUCT ROADMAP & FUTURE CAPABILITIES
-
Security Decision Support is the next stage of the TPZ roadmap.
As TPZ connects to more security systems, it is designed to bring related context together, help teams understand what matters and why, prioritize work, recommend actions to consider, and preserve the evidence behind recommendations and decisions.
Recommendations support human decision-making. They do not mean TPZ automatically carries out the recommended action.
-
Identity is TPZ’s first operating domain, not the end state of the platform.
The roadmap introduces additional integrations and security context so TPZ can connect information that currently lives across separate systems and help teams operate across a broader portion of the security program.
TPZ is designed to expand around the tools already in place rather than requiring organizations to replace them.
-
Governed Security Automation is the later stage of the TPZ roadmap.
It extends TPZ from helping teams understand and govern security work into executing authorized actions within defined policies, permissions, and limits.
The longer-term roadmap includes approved write-back and bounded automation. The goal is controlled automation rather than unrestricted autonomous action.
This is future product direction and is not how the current Beta operates.
-
Approved write-back means allowing an authorized action in TPZ to be carried out in a connected system after the appropriate governance and approval requirements have been satisfied.
For example, a future workflow could move from identifying an issue and approving a remediation decision to executing that approved change in the connected system.
Approved write-back is part of the product roadmap and is not a current Beta capability.
-
A closed-loop security process does not stop after identifying a problem or executing an action. It also evaluates whether the action produced the intended result and feeds that outcome back into the operating process.
TPZ's longer-term architecture is designed around a governed cycle of decision, execution, verification, and recovery. That includes determining whether an action succeeded, identifying drift or failure, and supporting recovery or rollback when appropriate.
The full closed-loop execution model is part of TPZ's broader roadmap, not the current Beta.
-
AI is intended to support TPZ’s broader decision-support capabilities by helping analyze security context, identify relationships and patterns, and support recommendations.
AI does not replace TPZ’s governance model. Decisions, permissions, evidence, and controls remain central to how the platform is designed to operate.
SECURITY, DATA & DEPLOYMENT
-
TPZ connects to supported systems and uses the security and identity context required for its workflows.
During the current Beta, that primarily includes information associated with identities, roles, permissions, MFA status, access activity, ownership, and related identity-governance context.
TPZ ingests and normalizes information from connected systems to support visibility, governance, workflow, history, and verification. The specific information retained, how long it is retained, and where it is stored depend on the supported deployment and technical configuration used for the engagement.
-
During Beta, TPZ connects to supported identity systems to pull the identity and access data required for its workflows. TPZ uses that connection to organize and evaluate information such as identities, roles, permissions, MFA status, access activity, and related governance context.
TPZ is not currently deployed inside the customer's environment. The connection and required permissions are established during onboarding based on the supported integration.
-
TPZ is designed around scoped access to connected systems.
During Beta, connections should provide only the permissions required to ingest and evaluate information necessary for supported identity-governance workflows.
Security work inside TPZ maintains clear ownership, permissions, decisions, and history. As future execution capabilities such as approved write-back are introduced, additional permissions would be separately governed according to the actions an organization chooses to authorize.
-
TPZ preserves the context around governed security work, including what was identified, who reviewed it, what decision was made, the reasoning or exception associated with that decision, and the resulting status.
For supported Beta workflows, TPZ can also re-evaluate or re-sync the relevant environment after remediation to determine whether the condition that originally triggered attention has changed.
This creates a clearer record from identification through decision, remediation, and verification.
-
TPZ depends on its integrations for current information from the systems it governs.
If a connection becomes unavailable, TPZ cannot continue receiving updated information from that source until connectivity is restored. Existing workflow and decision history can still provide context for work that occurred before the interruption.
COMPLIANCE, ARCHITECTURE & RESEARCH
-
TPZ is being designed to help organizations operate and preserve evidence in ways that support established security and compliance programs, including NIST, ISO 27001, SOC 2, and applicable sector-specific requirements.
TPZ does not replace the policies, controls, assessments, or audits required by those frameworks. Instead, TPZ is designed to make it easier to show what was reviewed, who owned the decision, what happened next, and what evidence supports the record.
-
TPZ is currently in the process of obtaining SOC 2 assurance as part of our commitment to building a security and governance platform that meets the expectations of regulated organizations.
While that process is underway, TPZ does not represent itself as SOC 2 compliant or as having completed a SOC 2 examination. We will update our compliance documentation as formal assessments are completed.
TPZ is also designed to help customers keep a clearer record of how security work was reviewed, decided, and resolved.
-
Evidence and traceability are central to the TPZ operating model.
TPZ is designed to preserve information around security work such as what was identified, who was responsible, what decision was made, the context behind that decision, and what ultimately happened.
During Beta, this begins with governed identity and access workflows, decision history, ownership, status tracking, and remediation verification. The broader architecture extends that model toward evidence being produced alongside governed decisions and execution rather than reconstructed afterward.
TPZ can support the audit process, but it does not replace an auditor or guarantee that an organization will satisfy a particular audit.
-
Patent Pending means that patent protection has been sought for aspects of the TPZ architecture and the relevant application or applications are still within the patent process.
It does not mean a patent has already been granted, and the final scope of any issued patent can differ from what was originally filed.
TPZ therefore uses Patent Pending, rather than describing the technology as patented.
-
TPZ's patent-pending architecture covers how security decisions can move from proposal and approval through execution, evidence, verification, and recovery while remaining bounded by defined permissions and authority. More detailed architectural concepts are available in our technical research and whitepapers.