vnceb

The End of NTLM and the Kerberos Reckoning

Tue, 14 Apr 2026 00:00:00 +0000

Independent Research Note | April 2026

Bottom Line

Microsoft is dismantling NTLM, the 30-year-old authentication protocol still used by 64% of Active Directory accounts, through a three-phase deprecation plan that will disable it by default in the next major Windows Server release. This transition represents the most significant shift in Windows enterprise authentication since Kerberos replaced NTLM as the default protocol in Windows 2000. Organizations that delay migration face escalating risk: at least 10 actively exploited NTLM CVEs were disclosed in 2024-2025 alone, and identity-based attacks became the leading intrusion vector in 2024, accounting for 30% of all breaches according to IBM X-Force. Meanwhile, Kerberos itself faces a parallel crisis. Newly discovered attack techniques like BadSuccessor and Golden dMSA exploit the very features Microsoft designed to replace legacy weaknesses, while Kerberoasting remains the dominant credential-theft technique across enterprise environments.

Key Findings

Microsoft formally deprecated all NTLM versions in June 2024 and published a three-phase deprecation roadmap on January 29, 2026. NTLMv1 has been fully removed from Windows 11 24H2 and Windows Server 2025. NTLMv2 will be disabled by default in the next major Windows Server LTSC release. Complete removal has no announced date.
At least 10 actively exploited NTLM CVEs were disclosed in 2024-2025, including two CVSS 9.8 vulnerabilities. The patch-bypass-repatch cycle around CVE-2025-24054 demonstrates that NTLM’s architectural weaknesses cannot be incrementally fixed. Cymulate bypassed Microsoft’s patches twice, achieving zero-click credential leakage on fully patched systems.
Kerberoasting activity increased 583% year-over-year (CrowdStrike), and new attack techniques targeting Windows Server 2025 features designed to replace NTLM (BadSuccessor, Golden dMSA) show that Kerberos itself requires significant hardening.
64% of Active Directory user accounts still regularly authenticate with NTLM (Silverfort), and Gartner estimates over 50% of organizations actively use it. Enterprise migration typically requires 18-22 months. The gap between deprecation intent and operational reality is substantial.
The passwordless authentication market has reached a tipping point. FIDO2 passkeys achieve a 93% login success rate versus 63% for traditional authentication. Microsoft made passkeys the default sign-in for all new accounts in May 2025. The market is valued at $18.8-24.1 billion and projected to reach $55-90 billion by 2030-2035.
Nation-state actors weaponize NTLM vulnerabilities within days of disclosure. CVE-2025-24054 was exploited eight days after patch release, with campaigns targeting Polish and Romanian government institutions traced to infrastructure previously linked to APT28 (Fancy Bear). Volt Typhoon, Scattered Spider, and Wizard Spider all incorporate NTLM exploitation into their toolkits.

Forward-Looking Assumptions

By mid-2027, Microsoft will disable NTLMv2 by default in the next Windows Server LTSC release, forcing organizations that have not migrated into explicit re-enablement through policy. Organizations without NTLM audit data by Q4 2026 will face emergency remediation timelines.
Through 2028, Kerberoasting will remain the dominant Active Directory credential-theft technique, despite RC4 deprecation efforts. Enterprises with mixed Windows Server 2019/2025 environments will encounter encryption type mismatches that slow AES-only enforcement.
By 2027, at least one major breach attributed to a BadSuccessor or Golden dMSA attack will force Microsoft to reclassify dMSA attack surface from “moderate” to “critical” severity. Akamai found 91% of environments had non-admin users with sufficient permissions to execute BadSuccessor. The attack surface is too broad for the current severity classification to hold.
By 2029, FIDO2/passkeys will be the default enterprise authentication method for over 50% of Fortune 500 companies. The combination of Microsoft, Google, and Apple platform support, 87% enterprise deployment or planning rates (FIDO Alliance), and regulatory pressure from CISA and NIST will drive adoption past the tipping point.
Through 2027, the most common cause of NTLM migration failure will be hidden NTLM fallback from misconfigured SPNs and IP-based access patterns, not legacy application hardcoding. Phase 1 auditing will reveal NTLM dependencies that organizations did not know existed, extending migration timelines beyond initial estimates.

Analysis

1. Microsoft’s Three-Phase Deprecation Roadmap

Microsoft formally deprecated all NTLM versions (LANMAN, NTLMv1, and NTLMv2) in June 2024, adding them to the Windows Deprecated Features list. NTLMv1 was not just deprecated but fully removed from Windows 11 24H2 and Windows Server 2025. NTLMv2 remains functional but receives no active development. On January 29, 2026, Microsoft published a definitive roadmap with three phases.

Phase 1 (available now) delivers enhanced NTLM auditing in Windows Server 2025 and Windows 11 24H2. New event IDs (4020-4033) capture which accounts use NTLM, which processes trigger it, why Kerberos failed, and the NTLM version negotiated. This visibility layer is the critical first step. Most organizations cannot enumerate their NTLM dependencies without it.

Phase 2 (H2 2026) addresses the technical barriers that force NTLM fallback. Two new capabilities ship: IAKerb (Initial and Pass Through Authentication Using Kerberos), which enables Kerberos authentication without direct domain controller connectivity, and Local KDC, which provides Kerberos for local account authentication. Microsoft estimates these cover roughly 5% of remaining NTLM usage, specifically the hardest cases involving workgroup-joined systems, IP-based access, and disconnected scenarios.

Phase 3 (next major Windows Server LTSC release) will disable network NTLM by default. Applications requiring NTLM must explicitly re-enable it through policy. Microsoft has been careful to clarify: “Disabling NTLM by default does not mean completely removing NTLM from Windows yet.” Complete removal has no announced date. The BlockNTLMv1SSO registry key will flip from audit to enforce mode by October 2026, and RC4 encryption for Kerberos, the cryptographic weakness enabling Kerberoasting, will be disabled by default for new domains in Q1 2026, with broader enforcement by mid-2026.

2. Kerberos Under Siege: Old Attacks Persist, New Ones Emerge

While Microsoft positions Kerberos as NTLM’s successor, the protocol faces its own expanding attack surface. Kerberoasting remains the single most impactful Active Directory attack technique. CrowdStrike documented a 583% year-over-year increase in Kerberoasting activity, and the Ascension Health ransomware breach in May 2024, which exposed 5.6 million patient records, was enabled by RC4 support in Kerberos. That breach prompted a U.S. Senator to demand an FTC investigation into Microsoft’s security defaults.

The traditional attack taxonomy (Golden Tickets, Silver Tickets, Pass-the-Ticket, AS-REP Roasting) remains fully relevant. But researchers have introduced increasingly stealthy variants that challenge conventional detection:

Diamond Tickets modify a legitimately issued TGT by decrypting it with the KRBTGT key, altering the PAC to add privileged group memberships, and re-encrypting. Because the ticket has a corresponding AS-REQ in KDC logs, it evades detections that look for forged tickets without authentication history.
Sapphire Tickets go further, replacing the PAC entirely with a legitimate PAC obtained through S4U2Self+U2U extensions. The resulting ticket contains no forged data whatsoever, making detection through PAC inspection effectively impossible.
BadSuccessor (disclosed by Akamai, April 2025) exploits Delegated Managed Service Accounts (dMSA), a Windows Server 2025 feature designed to mitigate Kerberoasting. An attacker with CreateChild permissions on any OU can create a dMSA that impersonates a Domain Admin. Akamai found 91% of environments had non-admin users with sufficient permissions to execute this attack. Microsoft classified it as “moderate severity” and released a patch in August 2025.
Golden dMSA (Semperis, July 2025) enables an attacker who obtains the KDS root key to brute-force valid dMSA passwords offline with only ~1,024 possible combinations, providing persistent access to all managed service accounts in the forest with no expiration.

The most critical Kerberos CVE of this period was CVE-2024-43639 (CVSS 9.8), an unauthenticated remote code execution vulnerability in the Windows KDC Proxy caused by an integer overflow. It required no user interaction and affected Windows Server 2012 through 2025. Microsoft’s PAC validation enforcement, completed in April 2025 after a multi-year rollout, represents the most significant defensive improvement, making Golden and Silver Ticket attacks harder to execute undetected.

3. NTLM’s 2024-2025 CVE Crisis

The volume and severity of NTLM vulnerabilities disclosed in 2024-2025 has been extraordinary, demonstrating that NTLM’s fundamental design cannot be patched into safety.

CVE	CVSS	Type	Exploited in Wild	Key Detail
CVE-2024-21410	9.8	Exchange NTLM relay	Yes	Prompted default EPA enablement
CVE-2024-43451	6.5	NTLMv2 hash disclosure (zero-day)	Yes	Used by Russian-linked UAC-0194, BlindEagle, Head Mare
CVE-2025-21311	9.8	NTLMv1 privilege escalation	Automatable	CISA flagged “total technical impact”
CVE-2025-24054	6.5	Hash disclosure via .library-ms	Yes	Exploited 8 days after patch; CISA KEV
CVE-2025-33073	High	NTLM reflection to SYSTEM	PoC available	Any domain user to SYSTEM on hosts without SMB signing
CVE-2025-59214	Medium	Third bypass of hash disclosure patch	Demonstrated	Zero-click on fully patched systems

CVE-2025-24054 illustrates the problem’s urgency. Patched on March 11, 2025, it was exploited in the wild by March 19, just eight days later. Check Point Research documented approximately 10 campaigns by March 25, targeting Polish and Romanian government institutions. SMB hash-collection servers were traced to Russia, Bulgaria, Netherlands, Australia, and Turkey, with one IP previously linked to APT28 (Fancy Bear). CISA added it to the Known Exploited Vulnerabilities catalog with a mandatory remediation deadline.

Cymulate Research Labs discovered that Microsoft’s patches for CVE-2025-24054 could be bypassed twice (CVE-2025-50154 and CVE-2025-59214), with the latter achieving zero-click NTLM credential leakage on fully patched systems. This pattern of patch-bypass-repatch underscores that NTLM’s architectural weaknesses cannot be incrementally fixed. They require protocol elimination.

Nation-state actors and ransomware groups actively weaponize these weaknesses. Volt Typhoon, APT28, Scattered Spider, and Wizard Spider all incorporate NTLM exploitation into their toolkits. 90% of ransomware breaches involve RDP abuse (Sophos), and groups like ALPHV/BlackCat, Akira, and RansomHub routinely leverage NTLM-based lateral movement to escalate from initial access to domain compromise.

4. Enterprise Migration Barriers

Despite the clear threat, enterprise NTLM elimination remains a significant operational challenge. Silverfort’s research found that 64% of Active Directory user accounts regularly authenticate with NTLM, and Gartner estimates over 50% of organizations still actively use it.

The primary obstacles are well-documented. Legacy applications (ERP systems, HR platforms, and industrial control software built before the 2000s) often hardcode NTLM with no Kerberos support. Third-party firmware in printers, network devices, and IoT equipment frequently embeds NTLMv1 with no upgrade path. Hidden NTLM fallback occurs when Kerberos fails silently due to misconfigured SPNs, IP-based access patterns, or missing DNS entries. Cross-forest trust scenarios and Exchange hybrid migrations add further complexity. Mandiant’s January 2026 release of 8.6 terabytes of NTLMv1 rainbow tables, enabling hash recovery in under 12 hours on $600 hardware, was a deliberate forcing function designed to eliminate any remaining justification for NTLMv1 retention.

Organizations following Microsoft’s recommended migration path typically plan 18-22 months for full NTLM elimination. The most heavily affected industries include manufacturing (50% of observed NTLM exploitation targets per Kaspersky telemetry), healthcare (the Ascension breach being the most prominent case), government (CISA assessments identify credential access as the most prevalent attack against federal agencies), and financial services (where strict compliance requirements both motivate and complicate migration timelines).

5. Vendor Landscape

The NTLM deprecation has catalyzed a competitive vendor landscape spanning detection, migration, governance, and replacement.

Microsoft is driving the transition most aggressively, with Entra ID as the centerpiece. Microsoft Entra Private Access (GA July 2024) acts as an OAuth/OIDC-to-Kerberos bridge, layering Conditional Access and MFA on legacy NTLM/Kerberos applications without code changes. Entra Kerberos (Cloud Kerberos Trust) turns Entra ID into a cloud-based KDC, enabling passwordless SSO to on-premises resources and is now the recommended deployment model for Windows Hello for Business. Windows Server 2025 ships with EPA enabled by default for AD CS and LDAP, Credential Guard enabled by default, and mandatory SMB signing.

Silverfort has emerged as the most prominent vendor specifically addressing NTLM security, offering the only solution that extends MFA to NTLM and Kerberos authentications without agents. Their research discovered that on-premises applications can bypass the Group Policy designed to block NTLMv1, creating what they called a “false sense of protection.” Gartner’s May 2025 report “A Well-Run Active Directory Requires Strong Identity Controls” named Silverfort as an example vendor in three categories.

CrowdStrike’s Falcon Identity Protection performs real-time inspection of NTLM, Kerberos, and LDAP traffic, with specialized detection for relay attacks, Kerberoasting, and Golden/Silver Ticket usage. Their acquisition of Preempt Security in 2020, whose researchers discovered critical NTLM bypass vulnerabilities, underpins deep protocol expertise.

Semperis focuses on AD resilience and recovery, with Directory Services Protector monitoring for NTLM-related indicators and a new Service Account Protection Essential (August 2025) specifically targeting Kerberoasting-vulnerable service accounts. Their researchers discovered the Golden dMSA attack and coordinated multiple CVE disclosures with Microsoft.

Cisco Duo made a significant competitive entry in 2025-2026, extending MFA directly to all Active Directory authentications, including CLI and legacy applications using Kerberos and NTLM. Cisco Identity Intelligence provides deep posture management, and Cisco Talos found nearly half of identity-based attacks in 2024 focused on Active Directory.

Delinea explicitly added Kerberos authentication support to Connection Manager in Q1 2025, noting it “mitigates risks associated with NTLM, including Pass-the-Hash, DCSync, NTLM relay.” Okta’s Agentless Desktop SSO explicitly requires Kerberos tickets; NTLM tokens cause authentication failure by design. Ping Identity and SailPoint operate at the federation and governance layers respectively, providing standards-based SSO and identity lifecycle management that inherently bypass NTLM.

6. Modern Alternatives Reaching Enterprise Maturity

The authentication stack replacing NTLM and password-based Kerberos is coalescing around three pillars: passwordless credentials, cloud identity platforms, and Zero Trust architecture.

FIDO2 and passkeys reached a tipping point in 2025. The FIDO Alliance reports that 87% of US and UK enterprises are deploying or planning passkey deployment for employee sign-ins. Passkeys achieve a 93% login success rate versus 63% for traditional authentication. Microsoft made passkeys the default sign-in for all new Microsoft accounts in May 2025, driving 120% growth in passkey authentications. Okta’s data shows phishing-resistant passwordless authentication grew 63% year-over-year, and workforce MFA adoption reached 70%.

Certificate-based authentication serves regulated environments requiring digital signatures, email encryption, and high-assurance identity proofing. Microsoft Entra CBA is now generally available, enabling X.509 certificate authentication directly to Entra ID without AD FS and classified as phishing-resistant MFA by both Microsoft and CISA. Federal agencies using PIV/CAC smart cards can authenticate directly to cloud resources, removing a lateral movement path through Active Directory.

Zero Trust architecture provides the strategic framework driving NTLM elimination. CISA’s Zero Trust Maturity Model v2.0 requires phishing-resistant MFA at the “Advanced” level and continuous identity validation at the “Optimal” level, both incompatible with NTLM’s implicit trust model. OMB M-22-09 mandates federal agencies achieve Zero Trust objectives including phishing-resistant MFA. Internationally, the EU’s NIS2 Directive, eIDAS 2.0 (requiring digital identity wallets by 2026), and PCI DSS 4.0 all strengthen authentication requirements. Eighty-one percent of companies are pursuing some form of Zero Trust strategy.

Recommendations for Security and Risk Management Leaders

Deploy Phase 1 NTLM auditing immediately. Windows Server 2025 and Windows 11 24H2 provide new event IDs (4020-4033) that map all NTLM dependencies. Without this data, migration planning is guesswork. Set a 90-day deadline for complete NTLM dependency inventory.
Enforce NTLMv2-only and block NTLMv1 now. Set LmCompatibilityLevel=5 across all systems. NTLMv1 is already removed from current operating systems. Mandiant’s rainbow tables make any remaining NTLMv1 usage an immediate compromise risk.
Begin RC4 deprecation for Kerberos as the single highest-impact defensive action. Kerberoasting depends on RC4. Disable RC4 for new domains immediately; plan AES-only enforcement for existing domains by mid-2026. Test thoroughly in mixed Windows Server 2019/2025 environments where encryption type mismatches cause authentication failures.
Enable EPA, SMB signing, and Credential Guard on all servers. These are the three controls that most effectively mitigate NTLM relay, pass-the-hash, and credential theft. Windows Server 2025 enables them by default; backport to older systems through Group Policy.
Block NTLM progressively, starting with domain controllers and certificate authorities. Add privileged accounts to the Protected Users group. Use the Negotiate package instead of explicit NTLM calls (often a one-line code change). Plan 18-22 months for full domain-wide NTLM blocking.
Audit dMSA permissions immediately. Akamai found 91% of environments have non-admin users with sufficient permissions to execute the BadSuccessor attack. Restrict CreateChild permissions on OUs and monitor dMSA creation events until Microsoft’s patch is widely deployed.
Invest in phishing-resistant authentication infrastructure. FIDO2 passkeys and certificate-based authentication through Entra ID are the long-term replacements for password-based protocols. Begin pilot deployments now; align with NIST SP 800-63B-4 requirements for AAL3 hardware-based authenticators.
Block outbound SMB (TCP 445) at the network perimeter. This prevents NTLM hash exfiltration to attacker-controlled servers, the technique used in CVE-2025-24054 campaigns. This is a low-effort, high-impact network control.

Market Outlook

The NTLM deprecation is creating distinct market dynamics across three vendor categories. Identity protection vendors (Silverfort, CrowdStrike, Semperis) are best positioned in the near term because they address the immediate operational challenge: detecting and controlling NTLM usage during the multi-year migration period. These vendors have a finite window of relevance tied to NTLM’s lifecycle, but the 18-22 month migration timeline and the long tail of legacy environments means that window extends through at least 2029.

Microsoft holds the strongest structural position. Entra ID, IAKerb, Local KDC, and the Windows Server 2025 security defaults form a coherent stack that addresses both the deprecation path and the replacement architecture. Organizations heavily invested in Microsoft infrastructure will find the migration path most natural, though multi-cloud and hybrid environments will require supplementary tooling.

The passwordless authentication market ($18.8-24.1 billion, projected to $55-90 billion by 2030-2035) reflects the scale of the broader transition away from password-based protocols. FIDO2/passkey vendors, cloud identity platforms, and Zero Trust architecture providers are the long-term beneficiaries. The organizations that treat NTLM elimination as a compliance checkbox rather than an architectural shift will find themselves repeatedly patching symptoms while the underlying protocol remains a liability.

The honest assessment: NTLM elimination is operationally harder than any vendor marketing suggests, and Kerberos hardening introduces its own risks. But the alternative, maintaining a protocol with a demonstrated pattern of unpatchable vulnerabilities while nation-state actors exploit them within days, is no longer defensible.

Key Sources

Microsoft documentation: NTLM Deprecation Roadmap (January 29, 2026); Windows Server 2025 Security Defaults; IAKerb and Local KDC announcements; Entra Private Access GA (July 2024); Entra Kerberos Cloud Trust documentation.

Vulnerability research: Check Point Research CVE-2025-24054 analysis (March 2025); Cymulate Research Labs CVE-2025-50154 and CVE-2025-59214 bypass disclosures; Akamai BadSuccessor disclosure (April 2025); Semperis Golden dMSA disclosure (July 2025); Microsoft CVE-2024-43639 advisory.

Threat intelligence: CrowdStrike 2025 Global Threat Report (583% Kerberoasting increase); IBM X-Force 2024 Threat Intelligence Index (30% identity-based breaches); Sophos Active Adversary Report (90% RDP abuse in ransomware); Mandiant NTLMv1 rainbow tables release (January 2026); CISA Known Exploited Vulnerabilities catalog.

Industry data: Silverfort NTLM usage research (64% of AD accounts); Gartner estimates (50%+ organizations using NTLM); FIDO Alliance enterprise deployment survey (87% deploying or planning); Kaspersky NTLM exploitation telemetry; Ascension Health breach disclosures (May 2024).

Government guidance: Five Eyes joint advisory “Detecting and Mitigating Active Directory Compromises” (September 2024, updated January 2025); NIST SP 800-63B-4 (July 2025); CISA Zero Trust Maturity Model v2.0; CISA phishing-resistant MFA fact sheet; OMB M-22-09.

Vendor sources: Silverfort NTLMv1 bypass research; CrowdStrike Falcon Identity Protection; Semperis Directory Services Protector; Cisco Duo AD authentication extension; Delinea Connection Manager Kerberos support (Q1 2025); Gartner “A Well-Run Active Directory Requires Strong Identity Controls” (May 2025).

The Audit Blind Spot: Why Workload Identities Escaped Review and Why That Era Is Ending

Wed, 08 Apr 2026 00:00:00 +0000

Independent Research Note | April 2026

Bottom Line

Most organizations cannot pass a rigorous audit of their non-human identity (NHI) controls today. PCI DSS 4.0.1, DORA, and NYDFS now explicitly require service account access reviews, inventory, and credential hygiene, yet the average enterprise still has 60% of its AWS IAM access keys older than one year (Datadog, State of Cloud Security 2024). The tooling market is real but immature. The AI agent identity problem is arriving faster than the standards to govern it. Security and risk management leaders who treat NHI governance as a 2027 initiative will find themselves remediating audit findings and incident response gaps simultaneously.

Key Findings

PCI DSS 4.0.1, effective March 2025, introduced the first explicit requirements for application and system account access reviews, password management, and interactive login prevention. QSAs report these controls were not explicitly covered in version 3.2.1, catching many organizations unprepared (Intersec Worldwide, Schellman).
DORA’s Regulatory Technical Standards are the most prescriptive NHI governance mandate globally, requiring financial entities to maintain service account inventories with documented owners, purposes, and periodic reviews at the same frequency as human privileged accounts. Early supervisory examinations in the Netherlands, Germany, and Ireland are requesting these artifacts now.
Every quantitative survey on NHI ownership gaps is vendor-sponsored. The widely cited “51% have no clear NHI ownership” figure comes from a CSA/Oasis Security survey (n=383, August 2025) where the vendor co-designed the questionnaire. We found no independent data to contradict it, but the number should be treated as directional, not definitive.
AI agent identity governance is arriving before the standards to support it. NIST’s CAISI initiative launched in February 2026 but will not produce finalized standards until 2027 at earliest. Meanwhile, analyst projections suggest 40% of enterprise applications will embed task-specific AI agents by end of 2026.
The CyberArk-Venafi integration is a sales success but not yet a product reality. Venafi appeared in 9 of CyberArk’s top 10 deals in Q1 FY2025. But the technology has had three owners in two years (Thoma Bravo, CyberArk, now Palo Alto Networks), and practitioners at Venafi’s own Machine Identity Summit in 2024 were still requesting “one dashboard, please” (Kraft Heinz CISO Ricardo Lafosse).
Credential rotation remains the most common source of self-inflicted NHI outages. Cloudflare suffered a 67-minute global write outage in March 2025 because a rotation script deployed new credentials to dev instead of production. Microsoft paused key rotation after a previous outage, which contributed to the Storm-0558 signing key compromise. Fear of breaking production is the primary reason organizations do not rotate credentials, and it is not irrational.

Forward-Looking Assumptions

By 2028, 60% of enterprises subject to PCI DSS, DORA, or NYDFS will receive audit findings specifically citing inadequate NHI access reviews, up from fewer than 15% in 2025. The control language is now unambiguous. Auditor interpretation will catch up to the text.
By 2027, fewer than 20% of organizations deploying AI agents will have implemented agent-specific identity governance controls. Standards lag is the root cause. Most will retrofit governance after incidents or audit pressure, not before.
By 2029, the standalone NHI governance market will consolidate into three categories: cloud-native platform features (Microsoft, AWS, Google), PAM-adjacent suites (Palo Alto/CyberArk, BeyondTrust), and pure-play NHI posture management for multicloud. Two of the five current pure-play vendors (Astrix, Oasis, Clutch, Entro, Token Security) will be acquired or fail to reach scale.
Through 2028, the majority of NHI governance programs will be owned by platform engineering or DevOps teams, not IAM or GRC. This is a problem. Platform teams optimize for velocity; they do not naturally build compliance artifacts. Organizations that do not create a federated governance model with IAM policy oversight will fail audits even if their technical controls are adequate.
By 2027, at least one G7 financial regulator will issue enforcement action explicitly naming NHI management failures as a contributing cause. The pattern is set: the OCC’s own service account breach (disclosed April 2025), the SEC’s SolarWinds victim penalties (October 2024), and DORA’s supervisory cycle all point to enforcement, not just guidance.

Analysis

1. The Audit Gap Is No Longer Interpretive

The compliance landscape shifted in 2024 and 2025. Where frameworks previously used vague language about “all accounts” or “system users,” the latest revisions name service accounts, application accounts, and machine identities with specificity that leaves little room for creative interpretation.

PCI DSS 4.0.1 (effective March 31, 2025) introduced Requirement 7.2.5.1, which requires periodic review of all access by application and system accounts and related access privileges, with management attestation that access remains appropriate. The review frequency is determined through a Targeted Risk Analysis, but the requirement is mandatory. Requirement 8.6.1 goes further: interactive login for system accounts must be prevented unless needed for an exceptional circumstance, and that circumstance must be documented and time-limited. Requirement 8.6.2 prohibits hardcoded passwords in scripts, configuration files, or source code. QSA firm Intersec Worldwide noted these controls were not explicitly covered in version 3.2.1, which left enforcement to individual QSA discretion. That discretion is gone.

CIS Controls v8.1 Safeguard 5.5 requires organizations to establish and maintain an inventory of service accounts with department owner, review date, and purpose, and to perform reviews at a minimum quarterly. The CIS Assessment Specification enforces this with a gating metric: if the last review was more than three months ago, the control automatically fails. This is the most operationally specific NHI requirement in any major framework.

NIST SP 800-53 Rev 5 addresses NHI through IA-4 (Identifier Management) and IA-5 (Authenticator Management), both of which explicitly list “service” alongside “individual, group, role, and device.” Control enhancement IA-5(7) prohibits embedding unencrypted static authenticators in applications or scripts. Control IA-9 (Service Identification and Authentication) requires unique identification and authentication of system services before establishing communications. These are not new to Rev 5, but their presence gives auditors a direct citation.

ISO 27001:2022 Annex A 5.15 applies access control to “humans and non-human entities on a network.” Annex A 8.2 restricts privileged access for “users, software components, and services.” Lead auditors are now interpreting this to include integration accounts, automation scripts, and backup agents (Stuart Barker, ISO 27001 Lead Auditor, HighTable.io).

SOC 2 remains principles-based. The AICPA Trust Services Criteria do not include a named service account control. But if an organization’s system description states it manages “all accounts,” auditors will test that claim against service accounts. The trend among Type II auditors is to expand access review testing to include NHIs, particularly under CC6.1 through CC6.3. Organizations whose policies say “all accounts” but whose reviews cover only human users are creating their own audit findings.

We believe the Big 4 audit firms are approximately 12 to 18 months behind the control text in their examination rigor. KPMG published “The Rise of Machine Identities” in 2025, the most visible public statement from any Big 4 firm. A 30-year financial industry veteran writing for the NHI Management Group reported that Big 4 auditor focus on NHI has increased substantially over the last 2-3 years and warned that organizations without NHI programs could face scrutiny soon. But we have not seen standardized Big 4 audit procedures for NHI controls. That gap will close.

2. AI Agents Are a New Identity Category, and Nobody Is Ready

AI agents are not service accounts with better marketing. They are fundamentally different: non-deterministic, capable of requesting permission escalation at runtime, able to spawn sub-agents, and designed to operate across multiple systems simultaneously. A service account calls a fixed API with fixed permissions. An AI agent decides at runtime which APIs to call based on reasoning. This distinction matters for identity governance because every assumption about static privilege assignment breaks down.

SailPoint’s 2025 survey found that 80% of organizations using AI agents observed them acting unexpectedly or performing unauthorized actions. That number should alarm anyone building agent-based workflows without identity controls.

The hyperscalers are responding, but unevenly. Microsoft Entra Agent ID is the most ambitious effort: a new identity primitive for agents with blueprints, an agent registry, conditional access policies, lifecycle governance with human sponsors, and identity protection. It is also still in public preview as of April 2026 and requires a Microsoft 365 Copilot license with Frontier enabled. The vision is right. The production readiness is not there yet. AWS Bedrock AgentCore Identity reached general availability in October 2025 with a more pragmatic, infrastructure-centric approach: existing IAM roles extended with agent-specific attributes, OAuth credential providers for third-party service access, and a Cedar-based policy engine in preview. AWS has no lifecycle governance or sponsor concepts. Google Cloud’s Agent Identity (preview) takes the strongest credential security approach with mTLS-bound certificate tokens that prevent replay attacks, but has the least mature governance layer. None of the three platforms fully addresses sub-agent spawning, delegation chain accountability, or cross-platform identity federation.

The OWASP NHI Top 10, published in 2025, was the first structured risk taxonomy for non-human identities. It ranks Improper Offboarding as the top risk, followed by Secret Leakage and Vulnerable Third-Party NHI. However, it focuses almost entirely on traditional NHIs. The OWASP Top 10 for Agentic Applications, released in December 2025, addresses agent-specific risks but does not connect them to identity governance frameworks. The two lists exist in parallel without integration.

NIST’s CAISI initiative, launched February 2026, is the first U.S. government program dedicated to AI agent standards. It includes an NCCoE concept paper on AI agent identity and authorization that identifies prompt injection and accountability gaps as leading vulnerabilities. But the Request for Information comment period closed in March 2026, listening sessions are scheduled for April 2026, and finalized standards are expected in 2027 at the earliest. The majority of first-generation enterprise agent deployments will go live before any NIST agent-specific standard exists. We do not yet know what good agent identity governance looks like in practice, and honesty about that gap is more useful than a premature framework.

3. The Vendor Market Is Funded, Fragmented, and Early

Workload Identity Management appeared as a distinct category in the 2025 Gartner Hype Cycle for Digital Identity, the first year it was recognized. Based on available evidence, the category sits near the Innovation Trigger or early Peak of Inflated Expectations. KuppingerCole published its first Leadership Compass for Non-Human Identity Management in 2025, formally establishing NHIM as a market segment. The analyst recognition is real. The market maturity is not.

Funding is substantial but frequently overstated. The “$400M+ in H1 2025” figure circulating in vendor marketing originates from a Doppler blog post (Security Boulevard, August 2025) and refers to all of 2025, not just H1. It also includes adjacent vendors beyond the NHI pure-plays. Our verified tally of pure-play NHI funding rounds through 2025: Astrix Security Series B ($45M, December 2024, Menlo Ventures), Oasis Security Series A plus extension ($75M total, 2024, Sequoia/Accel), Clutch Security Series A ($20M, 2024, SignalFire), Entro Security Series A ($18M, 2024, Dell Technologies Capital), Token Security Seed plus Series A ($27M total, through January 2025, TLV Partners/Notable Capital), and Defakto (formerly SPIRL) Series B ($30.75M, October 2025, XYZ Venture Capital). That totals approximately $216M in verified pure-play rounds through 2025. Adding Oasis’s reported $120M Series B in March 2026 and NHI-adjacent vendors (Aembit, Veza, Natoma) pushes past $400M across 2024 through early 2026. The investment thesis is clear. The “$400M in H1 2025” framing is marketing.

Practitioner feedback is thin. Astrix has the most independent validation: named a Cool Vendor by Gartner (2023), RSA Innovation Sandbox finalist, named sample vendor in the 2025 Hype Cycle, and 15.3% PeerSpot mindshare in NHIM as of March 2026. Gartner Peer Insights reviewers praise detection of leaked tokens and service account discovery but note onboarding could be smoother. Entro Security has the richest Gartner Peer Insights reviews, with users calling it an integral part of their cybersecurity strategy alongside a request for deeper AI-driven analysis capabilities. Oasis Security’s PeerSpot mindshare declined from 16.8% to 12.8% year over year, a signal worth watching for a vendor that exited stealth in January 2024. Clutch Security, Token Security, and Natoma have essentially no independent public reviews. CISOs evaluating these vendors are making bets on roadmaps, not proven production outcomes. Discovery and posture management are the proven use cases. Lifecycle management and threat detection are emerging. AI agent governance is aspirational across the board.

The CyberArk-Venafi story deserves particular scrutiny. CyberArk acquired Venafi for $1.54 billion in late 2024. Sales integration was immediate: Venafi appeared in 9 of CyberArk’s top 10 deals in Q1 FY2025. Product integration was targeted for 2025 (CLM plus secrets management) and 2026 (unified human and machine identity platform). Then Palo Alto Networks acquired CyberArk for $25 billion, closing in February 2026. Venafi has now had three owners in two years. Documentation still lives at docs.venafi.com. A Doppler competitive analysis noted that CyberArk’s architecture leans toward static identity models, which can be a poor fit for modern environments where machine identities are constantly created and destroyed. We believe the unified machine identity platform vision is now on Palo Alto Networks’ roadmap, not CyberArk’s, and should be evaluated on a 2028 or later timeline.

4. Credential Rotation Works in Theory and Breaks in Production

The operational reality of NHI governance is less about tool selection and more about a specific, uncomfortable question: do you know what will break if you rotate this credential? Most organizations cannot answer it.

Datadog’s State of Cloud Security 2024, based on telemetry from thousands of organizations, found that 46% of organizations still use unmanaged users with long-lived credentials. Among Google Cloud service accounts, 62% have access keys older than one year. Among AWS IAM users, 60% have keys older than one year. Andrew Krug, Datadog’s Head of Security Advocacy, concluded that it is unrealistic to expect long-lived credentials can be securely managed. This is the most authoritative data point available because it is based on actual infrastructure telemetry, not survey self-reporting.

The fear of rotation-induced outages is well-founded. Cloudflare’s March 2025 R2 outage lasted 67 minutes and caused 100% write failures globally because a rotation script omitted the --env production flag, deploying new credentials to dev while old credentials were deleted from production. Microsoft paused its key rotation process after a previous outage, which contributed to the delay that enabled the Storm-0558 signing key compromise. The Oasis Security team documented a Dropbox incident in 2024 where emergency rotation of an unrotated AD service account caused partial end-user disruption. CyberArk’s own 2025 survey (n=1,200, vendor-sourced) found 72% of organizations experienced certificate-related outages in the past 12 months, up from 45% reporting weekly outages compared to 12% in 2022.

The practitioner consensus, visible across Reddit, security conference talks, and vendor-neutral blogs, follows a consistent failure pattern: an identity is created for an immediate need, permissions are broadened to avoid friction, credentials persist because rotation feels risky, access reviews get rubber-stamped to avoid outages, and nobody is confident enough to remove anything. The CSA blog (February 2026) articulated the structural problem: access reviews were designed to answer a human-centric question about whether a person still needs access. That question does not translate to NHIs without dependency mapping, usage telemetry, and owner accountability.

SPIFFE/SPIRE represents the most credible path to eliminating long-lived secrets for workload authentication. Both are CNCF Graduated projects with named production adopters including Uber, GitHub, Square (Block), and Pinterest. HPE invested heavily in core development through its Scytale acquisition. But Defakto Security states that small-scale deployments take 6 to 12 months and complex deployments require 12 to 24 months with a core team of experts. Legacy systems that cannot speak mTLS remain a hard blocker. Cloud-native workload identity federation (AWS IAM Roles, Azure Workload Identity Federation, GCP Workload Identity) works within a single cloud but fragments across multicloud and hybrid environments. The secure path is clear. The migration path for legacy environments is not.

5. Nobody Owns NHI Governance, and the Surveys Proving It Are All Vendor-Funded

The CSA/Oasis Security survey (January 2026, n=383) found that 51% of organizations reported no clear ownership or accountability for NHI governance. Oasis financed the project and co-designed the questionnaire. A separate CSA/Astrix survey (September 2024, n=818) found that only 15% feel highly confident in preventing NHI attacks and only 20% have formal NHI offboarding processes. Astrix sponsored that survey. CyberArk’s 2025 Identity Security Landscape report (n=2,600) found that 88% define “privileged user” as solely human identities. CyberArk funded it. Entro’s 2025 analysis found 97% of NHIs have excessive privileges. Entro is a vendor. The Keeper Security RSAC 2026 survey (n=109) found 76% of NHIs are not governed under privileged access policies. Keeper is a PAM vendor with a convenience sample of 109 conference attendees.

We found no fully independent, non-vendor-sponsored survey that specifically quantifies NHI governance ownership gaps. The closest is the 2021 Ponemon/Keyfactor State of Machine Identity Management report (n=1,162), which used Ponemon’s independent methodology but was funded by Keyfactor and focused on certificates and keys rather than NHI governance ownership. The directional finding across all sources is consistent: NHI ownership is fragmented and unclear in most organizations. But the specific percentages should be treated as approximate. This is a data gap the analyst community has not filled.

In practice, HashiCorp (now IBM) observed that platform teams are often the de facto NHI managers: the people handling cloud IAM roles for microservices and certificate rotation for service mesh are typically platform engineers, not IAM staff. GitGuardian’s analysis found that the person who can answer most questions about an NHI is the developer who created it, which does not mean they are responsible for rotation or lifecycle management. The Gartner IAM Summit in December 2025 advocated a layered identity fabric model where Access Management, IGA, and PAM are interdependent layers that must work together rather than compete for ownership or visibility. ServiceNow added Non-Human and Agentic Identity Governance as a new domain in its IAM capability map, recommending organizations start with NHI discovery and ownership attribution.

Legacy PAM tools have structural limitations for NHI use cases. They are vault-centric (assuming persistent accounts), human-speed (manual checkout workflows), session-oriented (recording RDP/SSH, not API calls), and centralized (requiring vault connectivity). Ephemeral cloud workloads, serverless functions, and CI/CD pipelines do not fit this architecture. The CSA/Astrix 2024 survey found that 54% of respondents use PAM for NHI, but these tools are not specifically designed to address NHI security challenges. BeyondTrust and Delinea face similar architectural gaps. The Palo Alto Networks acquisition of CyberArk signals that PAM is becoming an infrastructure-level control rather than a standalone tool category, but the product integration timeline extends well past 2027.

6. Regulators Are Building the Enforcement Case

No U.S. or EU regulation uses the term “non-human identity.” But the enforcement infrastructure is forming around the underlying concepts, and the gap between regulatory intent and explicit NHI language is closing fast.

DORA is the most important development for financial sector CISOs. The Regulatory Technical Standards on ICT Risk Management, effective January 2025, require financial entities to maintain an inventory of service accounts, document the purpose of each, assign a human owner, prevent interactive use where not required, and review access at the same frequency as human privileged accounts. MFA for privileged accounts is legally mandated, not optional. Early supervisory examinations in the Netherlands, Germany, and Ireland are requesting these artifacts. The service account inventory requirement is, per practitioner reports, one of the most commonly missed items in initial DORA readiness assessments.

The FFIEC’s 2021 guidance on Authentication and Access remains the most NHI-explicit U.S. regulatory document. Footnote 2 defines “users” to include employees, third parties, service accounts, applications, and devices. The guidance requires authentication considerations for system-to-system communications. The irony is painful: the OCC, which issued this guidance jointly with other banking regulators, disclosed in April 2025 that its own Microsoft 365 tenant was compromised through a service account with administrative privileges that lacked MFA. The breach persisted for 20 months. It was reported to Congress as a major information security incident.

The SEC has not cited NHI by name, but its October 2024 enforcement actions against four SolarWinds victim companies penalized the minimization of credential compromise in public disclosures. Unisys paid $4 million for describing risks as hypothetical despite knowing that seven network credentials and 34 cloud-based accounts were compromised. Mimecast paid $990,000 for failing to disclose that a threat actor exfiltrated an authentication certificate used by approximately 10% of its customers. The FTC’s Drizly consent order (January 2023) explicitly cited failure to securely store AWS and database login credentials and failure to scan repositories for unsecured credentials such as usernames, passwords, API keys, secure access tokens, and asymmetric private keys. Personal liability was imposed on the CEO.

NYDFS 23 NYCRR 500 merits specific attention. The amended regulation, fully effective November 2025, requires Class A companies to implement PAM solutions and mandates MFA for any individual accessing any information system. There is a carve-out for service accounts that prohibit interactive login, but this creates risk rather than eliminating it. Organizations must ensure non-interactive service accounts truly cannot be used interactively, and must implement compensating controls.

The EU AI Act (effective in stages through 2027) requires that AI systems interacting with natural persons disclose they are AI (Article 50, effective August 2026) and that high-risk AI systems be registered in an EU database. But the Act is silent on how AI agents authenticate to other systems, manage credentials, or handle privilege escalation. It addresses “is this an AI?” but not “what can this AI access?” That gap will force supplementary regulation as autonomous agents proliferate.

Recommendations for Security and Risk Management Leaders

Inventory first, tool second. Before evaluating NHI vendors, run a discovery sprint using cloud-native tools (AWS IAM Access Analyzer, Azure Entra Workload ID, GCP Policy Analyzer) and open-source scanners (GitGuardian, TruffleHog) to establish baseline counts of service accounts, API keys, OAuth tokens, and certificates. You cannot govern what you have not counted. Set a 90-day deadline for initial inventory. Do not let it become a permanent project.
Map NHI controls to the audit frameworks you face now. PCI DSS 4.0.1 Requirements 7.2.5.1 and 8.6.1 through 8.6.3 are enforceable today. CIS Safeguard 5.5 requires quarterly reviews. DORA requires service account inventories with owners. Build the compliance artifact first, then automate it. If your organization is subject to DORA, treat the service account inventory as a regulatory deliverable with a named executive owner and a board-reportable status.
Adopt a federated ownership model, not a centralized one. IAM or GRC sets policy and defines standards. Platform engineering implements controls in CI/CD pipelines and manages cloud-native NHIs. Application teams own their application-specific NHIs with documented accountability. A central governance function (within the CISO organization) provides visibility, risk scoring, and audit coordination. No single team can own NHI governance at scale. The question is not who owns it but whether the accountability chain is documented and enforceable.
Separate the AI agent identity problem from the NHI backlog. Agent identity governance requires different controls: human sponsors, runtime behavioral monitoring, delegation chain tracking, and scope enforcement. Do not wait for the NHI backlog to be clean before addressing agent identity. Stand up an agent identity working group now that includes IAM, data science, platform engineering, and legal. Align to CSA’s AI Controls Matrix (July 2025) and NIST IR 8596 (draft) as provisional frameworks until NIST CAISI publishes finalized standards.
Evaluate pure-play NHI vendors for discovery and posture management only. That is where production-validated value exists today. Lifecycle management, threat detection, and agent governance are emerging capabilities without meaningful practitioner validation. Run a 90-day proof of value focused on discovery accuracy, ownership attribution, and secrets exposure detection. Do not sign multiyear platform commitments for capabilities that are still roadmap.
Begin SPIFFE/SPIRE evaluation for net-new workloads; do not attempt a legacy migration simultaneously. Workload identity federation eliminates long-lived secrets within a single cloud, but legacy systems that cannot speak mTLS remain a hard blocker. Apply secretless architectures to new Kubernetes-native and cloud-native workloads first. Use vaulted credentials with automated rotation for legacy systems. Accept that the transition will take 24 months or more and plan accordingly.

Market Outlook

The NHI governance market sits at a crossroads familiar to anyone who watched CASB, CSPM, or CIEM develop. There is genuine enterprise demand, validated by real audit pressure and breach history. There is real funding, with over $200 million in verified pure-play rounds through 2025. And there is significant risk of premature consolidation and vendor overreach.

The cloud hyperscalers are building native workload identity capabilities that will commoditize intra-cloud NHI authentication over the next three years. Microsoft’s Entra Agent ID, if it reaches general availability, could redefine expectations for agent identity governance within the Microsoft ecosystem. AWS AgentCore Identity is already GA. But none of the hyperscalers will solve cross-cloud NHI governance, secrets posture management, or multicloud lifecycle orchestration. That is the defensible wedge for pure-play vendors, and the ones that focus there will survive consolidation.

PAM vendors are rebranding around identity security. The Palo Alto Networks acquisition of CyberArk for $25 billion, combined with the prior CyberArk acquisition of Venafi for $1.54 billion, creates the largest identity security portfolio in the market. BeyondTrust exceeded $400 million ARR in June 2025 and acquired Entitle for CIEM. Delinea acquired Authomize and Fastpath. These are platform plays, not feature additions. But platform integration takes years, and CISOs should not confuse acquisition announcements with product delivery.

The honest assessment is this: we are in the first inning of NHI governance as a discipline. The compliance drivers are real and accelerating. The breach history validates the risk. The tooling is early but improving. The AI agent dimension adds urgency and complexity that the market has not yet absorbed. Organizations that start now, with inventory, ownership, and framework alignment, will be positioned to adopt better tooling as it matures. Organizations that wait for the market to settle will find themselves explaining to auditors, regulators, and boards why they treated machine identities as an afterthought while those identities outnumbered their employees 82 to 1.

Key Sources

Compliance frameworks: PCI DSS 4.0.1 (PCI SSC, 2024); CIS Controls v8.1 Assessment Specification (CIS, 2024); NIST SP 800-53 Rev 5 (NIST, 2020); ISO 27001:2022 (ISO/IEC, 2022); DORA RTS on ICT Risk Management (ESAs, 2024); NYDFS 23 NYCRR 500 (NYDFS, amended 2023); FFIEC Authentication and Access Guidance (2021).

Data sources: Datadog State of Cloud Security 2024; CSA/Oasis Security State of NHI Security Survey (January 2026, n=383); CSA/Astrix State of NHI Security Report (September 2024, n=818); CyberArk Identity Security Landscape 2025 (n=2,600); Keeper Security RSAC 2026 Survey (n=109); Ponemon/Keyfactor State of Machine Identity Management 2021 (n=1,162); SailPoint AI Agent Survey 2025.

Vendor and analyst sources: Gartner 2025 Hype Cycle for Digital Identity; KuppingerCole Leadership Compass: Non-Human Identity Management 2025; Gartner IAM Summit December 2025 (Sayers coverage); Astrix Security, Oasis Security, Entro Security, Clutch Security, Token Security, Defakto funding announcements; CyberArk Q1 FY2025 earnings; Palo Alto Networks/CyberArk acquisition filings; Doppler NHI Platform Comparison (August 2025).

Incident and enforcement sources: Cloudflare R2 Outage Post-Incident Report (March 2025); OCC Major Information Security Incident Disclosure (April 2025); SEC v. Unisys, Avaya, Check Point, Mimecast enforcement actions (October 2024); FTC v. Drizly consent order (January 2023); Harvard Law School Forum on Corporate Governance analysis of SEC cybersecurity enforcement (October 2024).

Standards and frameworks: OWASP NHI Top 10 (2025); OWASP Top 10 for Agentic Applications (December 2025); NIST CAISI Initiative RFI (February 2026); CSA AI Controls Matrix (July 2025); NIST IR 8596 draft; ServiceNow IAM Capability Map 2025.

Contributing to Open Source Again, With AI

Sat, 21 Mar 2026 00:00:00 +0000

Heads up: Much of the prose and code here are AI-assisted, but the ideas are my own.

Back at it

I used to be active in several open source projects. Life happened, priorities shifted, and at some point I just drifted away from it. No dramatic reason.

The new AI coding tools made me want to try again. The hard part of contributing to open source was never the coding itself, it was the ramp-up: understanding a new codebase, learning its conventions, figuring out which layer to hook into. That’s exactly what tools like Claude Code are good at, so I picked something small for a project run by a friend to see how it would go.

The project: Tiki Wiki

Tiki Wiki CMS Groupware is a PHP wiki/CMS/groupware app that’s been around since 2002. Big, old codebase, the kind where you’d normally spend days reading code before writing any.

I wanted to add Model Context Protocol (MCP) support. MCP is the open standard that lets AI assistants interact with external tools. WordPress has an MCP integration, Notion has one, Confluence has one. Tiki didn’t. The idea is that instead of opening a browser, logging in, navigating to a page, clicking edit, making changes and saving, you just tell your AI assistant “update the homepage” and it handles it over MCP. Read, create, search, edit, delete, view history, all through conversation.

The process

Planning

I described what I wanted, an MCP server that exposes Tiki’s wiki operations over HTTP, and Claude Code explored the codebase by reading the important files (tikilib.php, console.php, the wiki service controllers). We put together a plan that identified which Tiki service layer methods to wrap (create_page, update_page, get_page_info, list_pages, remove_all_versions), the bootstrap pattern to replicate from console.php, the PHP MCP SDK to use (mcp/sdk by PHP Foundation and Symfony), and 7 tools to implement across read and write operations.

Implementation

I don’t have PHP installed locally so we set up a Docker environment with MariaDB and PHP 8.1 Apache to develop against. Claude Code wrote the PHP files: an HTTP entry point (mcp.php) using Streamable HTTP transport, a server wrapper that builds the MCP server from tool classes using PHP 8 attributes, the 7 wiki tools each calling TikiLib’s service layer directly, a Bearer token auth provider using Tiki’s existing tiki_api_tokens table, and an output buffering context to prevent TikiLib from corrupting the JSON-RPC stream.

One thing worth explaining is that the tools call Tiki’s PHP service layer in-process rather than going through HTTP. TikiLib::lib('tiki')->create_page(...) is a direct function call because the MCP server runs inside the same PHP process as Tiki. Permission checks via Perms_Context just work, so whatever the authenticated user can do in the Tiki UI, they can do via MCP and nothing more.

Here’s how the pieces fit together:

MCP Client (Claude Code, etc.)
  │
  │  HTTP POST + Authorization: Bearer <token>
  ▼
Apache / Nginx
  │
  ▼
mcp.php
  ├── ApiTokenAuthProvider ──► tiki_api_tokens (validate + track hits)
  ├── Perms_Context (enforce user permissions)
  └── MCP SDK (StreamableHttpTransport)
        │
        ▼
      WikiTools (7 tools)
        ├── wiki_list_pages
        ├── wiki_get_page
        ├── wiki_get_page_history
        ├── wiki_search
        ├── wiki_create_page
        ├── wiki_update_page
        └── wiki_delete_page
              │
              │  in-process calls
              ▼
          TikiLib / WikiLib / HistLib
              │
              ▼
          MariaDB / MySQL

The bugs

A few things broke along the way. After calling update_page(), the next get_page_info() returned the old version because Tiki caches page info in memory and the cache wasn’t getting invalidated. The fix was passing skipCache=true after write operations. This is the kind of thing buried deep in a 10,000-line file that you find by staring at code for hours, or by having an AI trace the execution path in seconds.

The search was also broken because list_pages() defaults to exact_match=true, so searching for “MCP” wouldn’t find a page called “MCP Test Page” until we passed false explicitly. And the MCP SDK turned out to expect [ClassName::class, 'methodName'] as two strings for tool registration rather than an object and a string, so we had to register tool instances in the SDK’s PSR-11 container first.

Security

After the initial implementation I asked Claude Code to do a security audit of everything we wrote. It found 14 issues, some minor and some not minor at all.

The worst one was that the auth layer fell back to a default admin user when no token was provided. So if you didn’t send an Authorization header, you got full admin access. We ripped out the fallback entirely so every request needs a valid Bearer token or gets a 401. MCP sessions were stored in Tiki’s temp/ directory which is inside the web root, so we moved them outside the document root with restricted permissions. The token generation used uniqid() which is time-based and predictable, so we replaced it with random_bytes(32). Write operations were logging the IP as 0.0.0.0 instead of the actual client IP. A 403 error response included the username from the token when it should have been a generic message. And Apache CGI/FastCGI strips the Authorization header in some configs, which made token auth silently fail without handling the REDIRECT_HTTP_AUTHORIZATION fallback.

The auth fallback one really got to me. That was a “make it work first” shortcut that would have given unauthenticated admin access to anyone who could reach the endpoint. I caught it during review, but it’s the kind of thing that easily ships if you’re moving fast and not thinking about it.

Testing

We wrote 27 PHPUnit integration tests covering all 7 tools and the auth layer, running against a real database rather than mocks so they exercise the full path from tool method to TikiLib to MariaDB and back. The suite covers the full CRUD lifecycle from create through delete, error handling for things like duplicate pages and missing pages, input validation with pagination limits and sort mode allowlists, and the full range of auth scenarios including valid tokens, invalid tokens, expired tokens, missing tokens, and hit tracking.

The result

Once everything was working I connected Claude Code to the MCP server and could manage wiki content through conversation. “What’s on the main page?” reads the page, “create a new policy document” creates it with wiki syntax. The tools show up in Claude Code’s tool list and work like any other MCP integration. We packaged it as a single commit following Tiki’s conventions and submitted a draft merge request on GitLab with a Co-Authored-By: Claude trailer for transparency.

What I learned

The AI absolutely cuts through the ramp-up problem. Tiki’s codebase is 20+ years old with legacy procedural code sitting next to modern Symfony stuff, and understanding the bootstrap sequence, the service layer, the permission system and the caching behavior is the kind of thing that takes days of exploration normally. Claude Code did it by reading the source and what would have taken me most of a week took minutes.

But you can’t just let it run. The AI wrote code that fell back to unauthenticated admin access, stored sessions in the web root, and used a predictable token generator. I caught the auth issue during review and the others came out in a dedicated security audit pass that we did as a separate phase after implementation. Not “let’s hope we catch things during dev” but “stop, read every file, look for problems.” That’s when the real issues surfaced and I think doing it that way is important.

What’s next

This only covers wiki pages. Tiki has trackers, file galleries, calendars, forums, blogs and a lot more, and each could get its own set of MCP tools following the same pattern. The architecture is there, it’s just a matter of adding more tool classes.

If you’ve been thinking about contributing to open source but the ramp-up keeps stopping you, try it with AI tooling. Pick something small, be upfront about the AI assistance, and review everything before you submit because the AI will absolutely ship security holes if you let it.

Scaling OpenClaw's Agentic AI to Multi-User Environments with OpenFGA Authorization

Tue, 10 Mar 2026 00:00:00 +0000

Heads up: Much of the prose and code here are AI-assisted, but the ideas are my own.

The problem

Last week, CodeWall’s security agent broke into McKinsey’s AI platform Lilli in two hours. No credentials. A SQL injection on an unauthenticated endpoint gave them read/write access to 46.5 million chat messages, 57,000 employee accounts, and the system prompts controlling the AI’s behavior. One SQL UPDATE could have silently rewritten those prompts with no audit trail. The authorization layer around the AI was nonexistent.

That got me thinking about OpenClaw, which I use to run my own AI agents. Its security model is simple: one operator per gateway. If you’re the only person using it, that’s all you need.

But if three people want to share a gateway, you can’t give them different permission levels. Alice should have full control, Bob should be able to use agents but not change settings, Charlie should only be able to watch. Right now? You’d run three gateways. That’s not really a solution.

Same problem with community skills. If someone publishes a skill on ClawHub, you either trust it completely or you don’t install it. There’s no middle ground where an operator reviews it and unlocks it for specific users. And if you want agent A to call agent B’s tools, there’s no way to say “yes, but only these tools, and only if someone approved it.”

The missing piece is that these are all relationship questions. “Can this user invoke this tool via this agent?” depends on who, what, and whether there’s a delegation chain. You can’t answer that with a boolean config flag.

Why OpenFGA

I’ve been wanting to try OpenFGA on a real project for a while, and OpenClaw’s multi-user problem seemed like a good fit. It’s based on Google’s Zanzibar (the system behind Google Drive sharing, YouTube permissions, etc.), it’s CNCF-incubating, and it does exactly one thing well: relationship-based access checks.

OpenFGA stores relationships as tuples. “Alice is an operator of the main gateway” is a tuple. “The orchestrator agent can delegate to the researcher agent” is a tuple. You write tuples, then ask questions like “can Alice invoke the deploy tool?” and OpenFGA walks the relationship graph to figure it out. The transitive logic that turns into spaghetti if-else chains in application code becomes declarative.

The authorization model

This is the full model in OpenFGA’s DSL. It gets written to the OpenFGA store when the gateway boots:

model
  schema 1.1

type user
  relations
    define exists: [user]

type team
  relations
    define member: [user]

type gateway
  relations
    define operator: [user]
    define admin: [user]
    define user: [user]
    define viewer: [user]
    define can_admin: operator or admin
    define can_use: can_admin or user
    define can_view: can_use or viewer

type agent
  relations
    define exists: [agent]
    define parent_gateway: [gateway]
    define operator: operator from parent_gateway
    define allowed_user: [user, team#member]
    define can_delegate: [agent]
    define can_use: operator or allowed_user

type tool
  relations
    define parent_agent: [agent]
    define allowed_user: [user, team#member]
    define denied_user: [user, team#member]
    define can_invoke: can_use from parent_agent but not denied_user

type skill
  relations
    define publisher: [user]
    define allowed_gateway: [gateway]
    define trusted: [user]
    define can_use: [user]
    define can_install: allowed_gateway

type session
  relations
    define owner: [user]
    define participant: [user]
    define parent_agent: [agent]
    define can_read: owner or participant
    define can_write: owner or participant

type agent_delegation
  relations
    define source_agent: [agent]
    define target_agent: [agent]
    define approver: [user]
    define allowed_tool: [tool]
    define can_delegate: approver

A few things worth calling out:

Gateway privileges form a chain: operator > admin > user > viewer. Each level includes the permissions of the levels below it through computed relations. A viewer can read. A user can read and invoke tools. An operator can do everything.

Tool access uses a difference userset. can_invoke grants access to anyone who can use the parent agent, minus anyone on the deny list. So you can block Bob from the rm -rf tool without revoking his access to the agent itself.

Tools inherit from their parent agent via tupleToUserset. If you can use the agent, you can use its tools, unless someone explicitly denied you.

What it looks like in practice

I built three things on top of this model, with Claude Code doing most of the heavy lifting on implementation. Here’s each one with the actual tuples and what users see.

Multi-user teams

Say Alice is the operator, Bob is a regular user, Charlie can only watch, and Dave is some random who wandered into the channel. They’re all on Slack.

On boot, the gateway reads openclaw.json and writes these tuples:

user:alice   | operator | gateway:main
user:bob     | user     | gateway:main
user:charlie | viewer   | gateway:main

Alice asks the agent to change how deep research runs:

[Alice -> Slack] set the deep research thinking budget to high
[MyAgent -> Slack] Done. Deep research will now use extended thinking.

She’s an operator. The can_use check resolves through operator -> can_admin -> can_use. She can invoke tools and change agent configuration.

Bob asks the agent to run a deep research task:

[Bob -> Slack] deep research: there are thousands of passwordless
MFA vendors out there, why are new ones still popping up every
month, and why are we all still using passwords?
[MyAgent -> Slack] Starting deep research... Searched 31 sources.
Summary: adoption is blocked by legacy system integration costs,
not technology. New vendors keep launching because enterprise
procurement cycles create recurring market windows. Full report
attached.

He’s a user, which feeds directly into can_use. He can invoke tools normally, but admin operations (like changing agent configuration) would be denied.

Charlie tries to launch his own research:

[Charlie -> Slack] deep research on passkey adoption rates
[MyAgent -> Slack] Authorization denied: you do not have permission
to use the "deep_research" tool on this agent. Contact an agent
admin to request access.

But Charlie can still read Bob’s research output:

[Charlie -> Slack] what did Bob's MFA research find?
[MyAgent -> Slack] Bob's research found that passwordless adoption
is mostly blocked by legacy integration costs, not the technology
itself. New vendors keep appearing because enterprise procurement
cycles create recurring windows. Full report is in the thread above.

Charlie is a viewer. He has can_view but not can_use, so the agent won’t launch tools for him. But he can read results and ask follow-up questions based on what’s already in context.

Dave, who has no tuples at all:

[Dave -> Slack] hey can you help me
[MyAgent -> Slack] You are not authorized to use this gateway.

The unknownSenderPolicy config controls whether unknown senders get blocked or allowed with minimal permissions.

Identity resolution maps platform accounts to canonical users:

{
  "session": {
    "identityLinks": {
      "alice": ["slack:U04ABC123"],
      "bob": ["slack:U04DEF456"],
      "charlie": ["slack:U04GHI789"]
    }
  }
}

All three are on Slack, each mapped to their canonical user ID. The same identity resolution works across channels if someone is on multiple platforms.

Skill trust tiers

Skills get a trust level based on their source:

Source	Trust level	Default
`openclaw-extra`, `openclaw-bundled`	untrusted	Blocked until explicitly granted
`openclaw-managed`, `agents-skills-personal`, `agents-skills-project`	verified	Allowed
`openclaw-workspace`	privileged	Blocked until operator approves

Alice tries to run curl-fetch, a community skill from openclaw-extra:

[Alice -> Discord] /skill curl-fetch https://example.com
[MyAgent -> Discord] The "curl-fetch" skill is from an untrusted
source. Ask an agent admin to grant access.

An operator reviews the skill and decides it’s fine:

[Operator -> Discord] /auth grant user:alice can_use skill:untrusted/curl-fetch
[MyAgent -> Discord] Granted can_use on skill:untrusted/curl-fetch for user:alice

That writes one tuple:

user:alice | can_use | skill:untrusted/curl-fetch

Now it works:

[Alice -> Discord] /skill curl-fetch https://example.com
[MyAgent -> Discord] Fetching https://example.com... (200 OK, 12.4KB)

Privileged skills (workspace tier) fail closed. If OpenFGA is down, privileged skills get denied rather than allowed. Better to block a privileged operation by accident than to allow one.

Cross-agent delegation

Say you have an orchestrator agent that coordinates work and a researcher agent that searches the web. The orchestrator wants to send tasks to the researcher.

Without approval:

[orchestrator attempting sessions_send to researcher]
Agent "orchestrator" is not approved to delegate to agent "researcher".
Request approval from a gateway operator.

Grant it:

[Operator -> Discord] /auth grant agent:orchestrator can_delegate agent:researcher
[MyAgent -> Discord] Granted delegation: orchestrator -> researcher

Tuple:

agent:orchestrator | can_delegate | agent:researcher

Now the orchestrator can send tasks:

[orchestrator -> researcher session] Research the latest OpenFGA release
[researcher] Searching... Found: OpenFGA v1.11.6 released Feb 2026...

This is one-directional. The researcher can’t delegate back to the orchestrator unless that’s explicitly granted too. Neither can delegate to a coder agent without a separate tuple.

Conclusion

This started as a “let me see if OpenFGA even works for this” experiment. It went better than I expected. The authorization model maps cleanly to the problems agentic AI platforms actually have: who can use what, which agents can talk to each other, and which community-contributed skills are safe to run. The relationship-based approach fits naturally. I didn’t have to fight the model to express what I needed.

The McKinsey/Lilli breach is a reminder that AI platforms are becoming high-value targets, and the authorization layer is often the weakest part. As agents get more capable and start operating in shared environments, the question of “who is allowed to do what” stops being optional. Relationship-based authorization systems like OpenFGA give you a way to answer that question without building a mess of ad-hoc checks.

This is a proof of concept, not production code. There’s a detailed breakdown of what’s enforced at the code level, what’s modeled but not yet wired in, and what’s left to build in the project README. 126 unit tests and 16 e2e tests against a live OpenFGA instance.

What’s next: the Minecraft test

My next step is to put this in front of real users. I run OpenClaw at home where my kids use it to manage our family Minecraft servers. Right now they all have the same access, which means my youngest discovered he can kick his older brothers off the server whenever he feels like it. He thinks it’s hilarious. His brothers do not.

This is exactly the kind of problem the authorization model should solve. The oldest should have full server admin access: install plugins, change game rules, manage players. The middle one knows enough to handle day-to-day stuff like installing trusted plugins and tweaking game rules, but shouldn’t be kicking anyone. The youngest should only be able to do low-risk things like changing the weather or time of day. And any new tools added later should be blocked for him by default, so there are no more surprise kicks.

That’s probably the real test of whether this architecture holds up: not a synthetic Alice/Bob/Charlie scenario, but an actual household where one kid will absolutely find every edge case in your permissions model and exploit it for laughs.

If you’re building multi-user agents or thinking about authorization for AI platforms, I’d be interested to hear how you’re approaching it.

My Son's Spring Break Linux Experiment (and the WiFi Rabbit Hole That Almost Killed It)

Wed, 04 Mar 2026 00:00:00 +0000

My son wanted to try Linux over spring break. His theory: ditching Windows would get him better FPS out of his GPU. I knew it probably wouldn’t make a difference, but he was excited, and I was happy he wanted to give it a shot.

We installed Fedora 43 on his desktop and the WiFi didn’t work. The MT7902 chipset on his motherboard doesn’t have a supported driver in Fedora 43’s kernel. Freshly installed OS, no internet. He was already losing interest.

I fired up Claude Code in the terminal and described the problem. It found an experimental MT7902 driver built for the same kernel version that Fedora 43 ships. But it didn’t compile. The firmware installer was pointing at the wrong files, and Secure Boot was rejecting the unsigned module.

So Claude Code patched the Makefile to handle MOK signing, fixed the firmware paths, and wrote a DKMS config so the driver would rebuild itself on kernel updates. I enjoy digging into this kind of stuff, but my son would have been long gone by that point.

WiFi came up. We were finally online.

We pushed the fix to GitHub so nobody else has to deal with this: github.com/VnceB/mt7902_temp. Figured it was a good chance to show my son how open source works. Someone else’s code got us out of a jam, so we put our fix out there too.

Without Claude Code we just wouldn’t have done it. I don’t have hours to dig through kernel mailing lists and debug module builds, and a kid on spring break has zero patience for any of that. We got it working in one sitting and moved on. The FPS never improved, and his favorite game kept crashing mid-match during competitive play, which got him banned for a few hours. Without the FPS gain, he wasn’t about to gamble his profile’s reputation on more debugging sessions with dad. He’s back on Windows.