[Feature] Privileged Access Management (PAM) — agent-side elevation with mobile-app approval

[bdunncompany]

[Feature] Privileged Access Management (PAM), agent-side elevation with mobile-app approval

TL;DR

Build endpoint PAM into Breeze: user hits UAC → custom Breeze dialog → tech taps "approve" on their phone in under 10 seconds → the specific process elevates. Rule engine auto-handles repeats. Audit trail per request.

Closes the one feature gap that today forces every MSP on Breeze to bolt on a separate $300-$700/month tool (CyberFOX AutoElevate, Admin By Request, ThreatLocker Elevation, Idemeum, Evo Security). None of the major RMMs (NinjaOne, Atera, Level, Datto) ship endpoint PAM today. NinjaOne's most recent partner-facing window for their own PAM is "this year or 2027" (per a sales-channel update; the original April 2026 estimate of "2-5 months" has slipped). Breeze can ship first.

Realistic MVP: ~14 weeks single-dev calendar time with optimistic execution. The estimate is honest: ~10 engineering weeks plus ~2 weeks unavoidable external lead time (App Store review, EDR-vendor exclusion entries). Architecture concentrates the engineering risk in one well-isolated component, a Windows SYSTEM-service broker. The recommended interception path is ETW Microsoft-Windows-LUA provider subscription (documented, future-proof against Windows 11 24H2 Administrator Protection) followed by SYSTEM-context spawn onto WINSTA0\WINLOGON with SendInput injection of a rotated dormant-admin password. This matches the architectural pattern AutoElevate uses in production, with a faster and more durable event channel.

Open-source starting points are license-compatible (GPL-3 → AGPL-3 forward-compatible) for both Windows (MakeMeAdmin, partial, see Section 13) and macOS (SAP Privileges, integrate cleanly).

Asking for direction before writing code, same way as the watchdog-supervision Discussion #854.

---

1. Why this matters

Endpoint PAM does one job: keep standard users standard, but make admin approvals fast enough that nobody works around the policy. Without it, the choice is "make everyone a local admin" or "have the helpdesk RDP in every time someone needs to install a printer driver." Both lose.

The MSP-channel PAM market is real and growing. Verified pricing across the top tools (April 2026, MSP-tier, gathered while evaluating PAM for a real ~160-endpoint MSP fleet):

Tool	Vendor	Price (160 endpoints, MSP-tier)	What it does
AutoElevate	CyberFOX (independent; Feb 2026 9-figure raise led by Level Equity)	$2.10-$2.20/ep/mo = $336-$352/mo, 1-year minimum	UAC interception, mobile approval, rule engine
Idemeum Full Platform	Idemeum	$2.00/ep/mo (monthly) / $1.60 yearly = $256-$320/mo	Elevation + allowlisting + Cloud LAPS + Entra JIT
Idemeum JIT-only	Idemeum	$50/tech/mo monthly / $40 yearly = $120-$150/mo for 3 techs	JIT admin only, no agent-based elevation
ThreatLocker Elevation	ThreatLocker	Bundle-only, est. $3-4/ep = $480-$640/mo	Elevation + Ringfencing + Allowlisting + Storage/Network Control
Admin By Request	Fasttrack Software (Denmark)	Free up to 25 endpoints + 10 servers; paid quote-based 25-license increments	UAC interception, mobile approval, AI auto-approval
Evo Security	Evo Security (Austin TX, independent)	Quote-based, MSP-focused	MFA + SSO + RADIUS + Help Desk Verification + tech PAM + end-user PAM (broader bundle than AutoElevate)

For a Breeze MSP customer with ~160 endpoints, shipping PAM in-box saves them $250-$650/month per tenant and removes one vendor relationship.

This is not abstract. The MSP whose feedback drove this Discussion currently pays for ScreenConnect's bundled Privileged Access ($425/mo) to handle elevation requests; pure-RMM stacks (Atera, NinjaOne, Level, Datto RMM) have no equivalent, so customers stack one of the tools above. NinjaOne is openly telling partners their own PAM has slipped to "this year or 2027" (was "2-5 months out" in April 2026). The window to be first in the category is wide open.

---

2. What we're building (MVP scope)

End-user experience (Windows endpoint)

1. User runs an installer or any process that triggers UAC.
2. Breeze SYSTEM-context service detects the elevation request via ETW (Microsoft-Windows-LUA provider, event 15006 "ConsentUI_SwitchDesktop", fires before consent.exe paints its UI).
3. Breeze agent shows its own dialog on the user's normal desktop: "Allow Mozilla-Firefox-Installer.exe to run as administrator? A request will be sent to your IT team."
4. User clicks "Request access," optionally enters a one-line reason. Request flows to the tech via the existing API + WebSocket bus.
5. The native consent.exe prompt is allowed to render on the secure desktop in parallel, but with no input from the user, it sits idle awaiting credentials.

Technician experience (mobile-first)

6. Push notification on phone (iOS + Android): "Sarah at Acme Corp wants to elevate Mozilla Firefox installer. [Approve] [Deny] [View]"
7. Tech taps Approve on the lock-screen action. Sub-10-second median target from user click to elevated process running.
8. Optional: "Approve + Remember (auto-approve at this org for 30 days)" creates a rule.
9. Web fallback at /pam/requests shows the same queue for techs at desk.

Elevation execution (where most of the engineering risk lives)

10. On tech approval, the SYSTEM-context broker:
    • Promotes a dormant local account ~breeze_elev (or similar) to local Administrators
    • Rotates its password to a random value via NetUserSetInfo
    • Spawns a child process with STARTUPINFO.lpDesktop = "WINSTA0\\WINLOGON" (the secure desktop)
    • The child uses SendInput to type the rotated credentials into the still-pending consent.exe prompt
    • Demotes the account and re-randomizes the password within milliseconds
11. The original elevated process spawns under the elevated session. No admin password ever in the user's hands.

This is the same architectural pattern AutoElevate uses in production (documented by their integration partner E-N Computers and inferred from the architectural constraints, see Section 5). The ETW-based detection layer is a documented improvement over the UI-Automation-polling approach commonly assumed.

Rule engine

12. Each subsequent identical request matches a rule and auto-approves with no notification.
13. Rules scoped: device → site → organization → partner (all four levels exist already in Breeze's RLS model).
14. Match criteria: signer certificate, file hash, file path, parent process, time-of-day window, user OR AD-group of the requester.
15. Verdicts: auto-approve, auto-deny, require-approval, ignore (let native UAC through unchanged).

Audit

16. Every request, auto-decided or human-decided, generates an agent_logs row with requester, machine, executable details, rule match (if any), approver, latency-to-decision, outcome.
17. The existing agent_logs.fields column is jsonb, so PAM event rows can be added without schema changes (apps/api/src/db/schema/agentLogs.ts, verified).
18. Existing audit-log UI surfaces these alongside everything else; existing alert templates can fire on pam.elevation.denied or pam.elevation.rate_high.

That's the MVP.

---

3. Why mobile-app approval is non-negotiable

The incumbent product (AutoElevate) markets the mobile-tap approval as the killer feature. The competitive review evidence backs this with a twist: AutoElevate's mobile app is the highest-complaint surface of the product (3.0/5 on iOS App Store, multiple reviews citing forced logouts mid-session, inconsistent push, missing biometric quick-approve, verified May 2026, App Store listing). That's both the bar to clear and the lane to win.

What "mobile-first" means concretely for Breeze:

• Lock-screen actionable notifications. The tech approves without unlocking the phone or opening the app. APNs and FCM both support this; the request payload fits in the notification.
• Biometric quick-approve. Face ID / Touch ID on iOS, BiometricPrompt on Android. Tap notification → biometric prompt → approved. Sub-5-second flow.
• Long-running session resilience. If AutoElevate's logout-mid-session bug is the chore(deps): bump node from 20-alpine to 25-alpine in /apps/api #1 complaint, we don't ship a session that expires inside a working day. Refresh tokens, silent re-auth, the basics.
• Web fallback for the desk path. Same approval queue at /pam/requests, same actions, same audit. A tech at their workstation should never need to pick up their phone, but the phone is the default when away from the desk.

The path: Progressive Web App (PWA) first, native shells (iOS + Android via Capacitor) immediately after for the lock-screen push reliability. PWA gives us 80% of the mobile UX in week 1. Native shells give us the lock-screen and biometric reliability that turns it from "works" to "feels instantaneous." Both worth doing; PWA in Phase 1, native in Phase 3.

App Store rejection risk is empirically LOW for this category. Three PAM vendors already have approval apps live in the App Store with no documented rejection history:

• AutoElevate Notify (id 1413994912, in store since July 2018)
• ThreatLocker Admin (id 1595136398)
• BeyondTrust Access Console (id 1032400097)

Evo Security's equivalent is Evo Authenticator (id 1441463618, in store since April 2019 per version history, added end-user elevation in v5.1.0 July 2025).

Apple does not categorically block remote-admin tooling. First-submission review for a security app typically lands one Guideline 5.1.1 (privacy) cycle; budget 1-3 weeks calendar.

---

4. Architecture overview, what's already in Breeze that we reuse

Breeze's last 60 days of merged work has accidentally pre-built ~60% of the PAM scaffolding. Verified against actual Breeze source files:

Capability needed	What Breeze has today (verified file:line)	Net work
Per-org/per-site/per-device rule scope	4-tenancy-shape RLS schema with breeze_has_org_access() (apps/api/src/db/index.ts); direct fit	Add 2 tables (elevation_rules, elevation_requests) using shape #1 (direct org_id column). No new tenancy patterns.
Real-time tech notification	Server-side WS broadcaster in apps/api/src/routes/agentWs.ts:2209 (sendCommandToAgent) + apps/api/src/routes/agentWs.ts:2252 (broadcastToAgents); browser-side useEventStream hook at apps/web/src/hooks/useEventStream.ts already subscribes to typed events over WS.	One new event type pam.request.created. Existing hook reused as-is. ~2 days.
Rule-evaluation pattern	apps/api/src/services/scriptSeverity.ts ships a tiered match pattern (negative-exit → explicit-map → fallback). The pattern generalizes, but PAM needs multi-criteria matching (signer AND hash AND path AND parent) which is meaningfully more complex than a key lookup.	Write a new matcher; reference the existing tiered-fallback style. ~3 days.
Audit logging	apps/api/src/services/auditEvents.ts:117 writeRouteAudit() + apps/api/src/db/schema/agentLogs.ts (the fields column is jsonb, accepts arbitrary detail shapes).	None. Pattern is in place.
Approval UI	The 4-tab DNS Security page just shipped in #847 (Overview/Rules/Requests/Audit) is the exact shape PAM needs.	New page at /pam, copy-paste the DNS scaffold + new content. ~1 week.
MFA gate on tech approve	requireMfa() middleware exists across the API (used in apps/api/src/routes/devices/commands.ts:185 and many others).	None.
Per-endpoint local config cache	Verified: agent writes agent.yaml (mode 0640) and secrets.yaml (mode 0600) via atomicWriteFile at agent/internal/config/config.go:418-454. Not HMAC'd; ACL-based protection.	Add a third file pam-rules.yaml (same pattern) at NTFS ACL'd path. ~half a day.
Push notification (browser)	None today.	Web Push API via standard VAPID flow. New service-worker registration. ~2 days.
Push notification (native mobile)	None today.	APNs + FCM bridge in the API + native shell apps. ~1 week server-side + 2-3 weeks per platform shell.
Mobile-app shell	None today.	PWA first (works on every phone with a browser), Capacitor wrapper for iOS + Android in Phase 3.
Code-signing pipeline (Windows)	Verified: .github/workflows/release.yml uses Azure Trusted Signing via azure/artifact-signing-action@v2.0.0 with separate cert profiles for prerelease (AZURE_CERT_PROFILE_PRERELEASE) and production (AZURE_CERT_PROFILE_PROD). Already signs breeze-agent.exe, breeze-watchdog.exe, breeze-backup.exe, breeze-desktop-helper.exe, plus MSIs.	Add the new breeze-elevation-broker.exe to the existing sign step. ~2-4 hours of YAML changes. No new cert procurement.
Code-signing pipeline (macOS)	Verified: uses Apple Developer ID Application + notarization via notarytool, hardened runtime entitlements at agent/entitlements/agent-macos.entitlements.plist.	Add new macOS broker binary to the existing codesign loop. ~2 hours.

This is the part that makes shipping PAM realistic, not aspirational. A pure greenfield product would take 6+ months. With Breeze's current scaffolding the work concentrates in one place: the Windows broker binary.

---

5. The hard part: the Windows broker

This is where 80% of the engineering risk lives. Architectural constraints first, then the recommended architecture, then alternatives.

Architectural constraints (verified from Microsoft docs and reverse-engineering of public PAM behavior)

1. consent.exe runs at SYSTEM/High IL on WINSTA0\WINLOGON (the secure desktop). Source: Microsoft Learn, How UAC works. Only Windows processes can natively access this desktop.

2. A third-party process reaches the secure desktop via exactly two documented paths:

   • (a) A SYSTEM-context parent uses CreateProcessAsUser with STARTUPINFO.lpDesktop = "WINSTA0\\WINLOGON". This works because SYSTEM has the SE_TCB_NAME privilege and broad desktop access. Documented in working code by 0xpat (Malware development part 7).
   • (b) A binary manifested with uiAccess=true, signed by a cert chained to a Trusted Root CA, installed under %ProgramFiles%. Source: Microsoft Learn, UIAccess in secure locations.
   • Path (a) is what production PAM tools use. Breeze already runs the agent as a SYSTEM service, so (a) is the architecturally consistent path.

3. SendInput from a non-secure-desktop process is silently dropped when targeting the secure desktop (PCReview thread, multiple sources). The credential injection MUST happen from a SYSTEM-context child that is itself on WINSTA0\WINLOGON.

4. UI Automation (UIA) from the user's desktop cannot read controls on the secure desktop. So polling consent.exe via UIA from a non-secure-desktop process, what an earlier draft of this Discussion proposed, does not work. Any UIA-based detection has to run from a process already on the secure desktop, which loses the latency benefit.

5. PsSetCreateProcessNotifyRoutineEx is kernel-mode only. Requires a signed driver. Higher EV-signing burden, attack-surface considerations, HVCI implications.

Recommended architecture: ETW + SYSTEM-spawn + SendInput

The cleanest legal third-party path:

1. Detection: SYSTEM-context broker subscribes in real time to the Microsoft-Windows-LUA ETW provider (GUID {93c05d69-51a3-485e-877f-1806a8731346}, manifest reference). The relevant events:

   • 15001/15002 ConsentUI_GetUserDesktopSnapshot (start/stop), fires when consent.exe captures the user's desktop bitmap
   • 15006/15007 ConsentUI_SwitchDesktop (start/stop), fires when consent.exe switches to the secure desktop. This is the trigger. It fires before consent.exe paints its UI.
   • 15022/15023 ConsentUI_ExperienceStart/Stop, fires during the consent prompt lifecycle
   • 15031 Elevation Approved, 15032 Elevation Denied, under Administrator Protection (Win11 24H2+), these replace the older flow. Same provider, future-proof.
   • 16001-16011 AppInfo perf-track events with UACElevateFileID field, let us correlate the elevation to the originating user-mode process.

2. Display Breeze dialog on the user's normal desktop, on receipt of 15006. The user sees only the Breeze dialog. consent.exe in parallel paints its native dialog on the secure desktop but is idle awaiting credentials.

3. Request approval over the existing WebSocket + push notification path (Section 4 covers the plumbing).

4. On approval: SYSTEM-context broker:

   • Promotes ~breeze_elev to local Administrators (NetLocalGroupAddMembers)
   • Rotates its password to a random value (NetUserSetInfo, USER_INFO_1003)
   • Spawns a tiny child with STARTUPINFO.lpDesktop = "WINSTA0\\WINLOGON"
   • Child uses SendInput to type the rotated credentials into the consent.exe prompt
   • On the consent.exe-process-exit ETW event (15007), demotes the account and re-randomizes the password

5. On denial: SYSTEM-context broker spawns a SYSTEM child on WINSTA0\WINLOGON that uses SendInput to type Escape into consent.exe, dismissing the prompt. Same pattern.

Why this is the right architecture:

• ETW is event-driven and lower-latency than UIA polling
• ETW is language-invariant (the events fire regardless of consent.exe's localized UI)
• The Microsoft-Windows-LUA provider is the documented telemetry channel; future Windows changes that re-architect consent UI (such as Administrator Protection) will keep this provider working, the LUA events 15031/15032 are explicitly added for the AP path
• WMI __InstanceCreationEvent on Win32_Process is too slow (polling, min WITHIN 1, fires AFTER process creation per Microsoft archive). Discard.
• A kernel-mode filter driver (the PsSetCreateProcessNotifyRoutineEx path) is overkill for MVP, AutoElevate ships a driver but only for their Blocker feature, not for elevation detection (CyberFOX - Managing Blocker Rules).

Effort estimate for this path

Sub-component	Weeks
SYSTEM service skeleton (.NET 8 or Go; choose to match existing Breeze agent stack)	0.5
ETW subscriber for Microsoft-Windows-LUA + event parsing + dedup against re-fires	1
User-mode UI dialog process (per-session, IPC to SYSTEM service via named pipe)	1
~breeze_elev dormant account creation + password rotation + group membership management	1
Secure-desktop spawn + SendInput injection + denial path	1.5
Offline rule cache (HMAC'd JSON in %ProgramData%\Breeze\pam-rules.json, NTFS ACL'd to SYSTEM)	0.5
Locale handling, non-English Windows fuzz testing, error paths	1
Integration tests + end-to-end test on Windows VM matrix	1.5
Windows broker subtotal	~8 weeks

Alternative paths (for context)

Path B, Bypass consent.exe entirely with CreateProcessAsUser + restricted token. Cleaner architecturally; user never sees consent.exe. Risk: requires a different elevation model (token-mixing via LogonUser + CreateProcessAsUser), which doesn't match the user's mental model of "approve UAC." Most PAM vendors don't do this for end-user elevation; they use it for tech-side JIT admin (Evo Technician Elevation). Skip for MVP; consider for Phase 6 as a per-rule option.

Path C, Custom Credential Provider. Replace CredentialProvider COM interface, render Breeze UI inside consent.exe's existing flow. Cleanest from a Microsoft-design-intent perspective. Risk: CredentialProviders are gnarly C++ COM work, ~8-10 weeks, AV-scrutiny much higher. Bookmark for Phase 6+, not MVP.

Path D, Kernel-mode minifilter driver. What AutoElevate uses for their Blocker feature. Not appropriate for elevation detection, the ETW path is documented, supported, and equivalent latency for this use case. Driver work belongs to a future feature (process behavior monitoring, AV-style hooks), not PAM.

Windows 11 24H2 Administrator Protection compatibility

The biggest forward-looking risk. Administrator Protection (AP) replaces the legacy split-token UAC model with a hidden, profile-separated system-managed admin account that materializes a fresh elevated token per request and destroys it after the process exits. Sources: Microsoft Learn, Administrator protection, Project Zero teardown.

Current state (verified May 2026): AP shipped in KB5067036 (October 2025) but Microsoft pulled the feature flag on December 1, 2025 due to compatibility regressions. It is currently disabled even on machines that toggled it on. Sources: BleepingComputer, Patch My PC, 4sysops. Microsoft's own doc says it "will roll out at a later date."

Implications for our broker:

• The Microsoft-Windows-LUA ETW provider's events 15031 (Elevation Approved) / 15032 (Elevation Denied) are explicitly documented as the AP telemetry channel. Our detection layer is future-proof.
• The credential-injection layer is not future-proof under AP. AP elevations require Windows Hello/PIN/credential prompt rendered by a system-managed CredentialUIBroker.exe, there's no consent.exe credential field for SendInput to target, and no third-party-replaceable credential surface.
• When AP becomes mandatory (unknown date), our elevation primitive will need to switch to a different model. Options at that point: (1) prompt user to authenticate with Hello/PIN, with Breeze gating whether the prompt appears at all based on the approval workflow; (2) move to CreateProcessAsUser-based elevation entirely (Path B above).
• No PAM vendor has shipped AP-compatible code yet. CyberFOX's agent changelog through v2.10.27 (2025-09-09) makes no mention of AP, 24H2, or 25H2 (CyberFOX Agent Changelog). Same for ThreatLocker, Admin By Request, Evo Security. Breeze is not behind the field here.

Known interaction: N-able / consent.exe deadlock

Worth knowing because Breeze customers commonly stack other RMM/security agents. There is a documented production-breaking interaction between N-able N-Central agent (Framework.dll versions through 2025.4.0.16 and 2026.1.0.518) and ConsentUX.exe on idle or locked machines: UAC prompts accept credentials then hang for 4-5 minutes due to a deadlock in N-able's signature-verification hooks. N-able shipped Framework.dll hotfixes through partner support. Source: Microsoft Q&A 5733506. Any UAC-touching code Breeze ships needs to be vetted for similar deadlock potential with the agent stack our customers actually run.

CVE-2026-20824, January 2026 Credential UI hardening

Microsoft tightened the rules on which processes can request UIACCESS and added "input source validation … verifying input originates from physically connected input devices or processes running with specific, highly restricted privileges." This was tracked as CVE-2026-20824 (WindowsNews.ai writeup). Impacted: TeamViewer, AnyDesk, RDP. PAM brokers that inject SendInput from a SYSTEM child on WINSTA0\WINLOGON are not explicitly named, but the language suggests the SYSTEM injection path still works while non-SYSTEM UIAccess injection is squeezed. Worth verifying empirically before MVP ships.

---

6. The mobile-app stack

Phase 1, PWA (Week 1)

• Single-page app served from /pam-mobile with manifest + service worker
• Web Push API via VAPID for notifications
• Add-to-Home-Screen instruction in tech onboarding
• Works on every modern phone, no app store, no review cycle
• Limitations: iOS Web Push only works for installed PWAs (Safari 16.4+) and notifications don't show on lock screen the way native does; biometric quick-approve via WebAuthn works but is slightly less polished than native

Phase 3, Native wrappers (Weeks 11-13)

• Capacitor wraps the existing PWA into a native iOS + Android shell
• APNs (iOS) and FCM (Android) for true lock-screen actionable notifications
• Native biometric prompt for the approve action (Face ID / BiometricPrompt)
• Shipped to App Store + Play Store under "Breeze Approve" (or similar)
• 90% of code shared with PWA; 10% per-platform shim
• App Store review: 1-3 weeks calendar based on category precedent (Section 3)

Why this order

PWA gets us to "techs can approve from their phones" in week 1. Native gets us to "techs can approve from their lock screen in 5 seconds without unlocking" by month 3. PWA unblocks the rest of the product so we can ship Phase 1 to pilot endpoints without waiting on App Store review.

---

7. Honest effort estimate (single dev, calendar weeks)

Phase	Scope	Weeks
0, Alignment	This Discussion + maintainer green light + decision on placement of broker (in breeze-agent, in breeze-watchdog, or new breeze-elevation-broker binary)	0 (this doc)
1, Rules + Audit + Web UI + PWA	Backend tables, rule evaluation, /pam React page (4 tabs), technician approval flow over existing WebSocket, PWA shell with web push. Zero Windows broker changes. Already useful: techs can manually elevate scripts via the existing script-execution path with the new approval gate.	3
2, Windows broker (ETW-based path, Section 5)	SYSTEM service + user-mode UI process, ETW subscriber, dormant local admin account, secure-desktop spawn + SendInput injection, offline rule cache, locale handling	8
3, Native mobile (iOS + Android via Capacitor)	Wrap PWA in native shells, wire APNs + FCM, biometric quick-approve, App Store + Play Store submission	3 + 1-3 calendar for App Store review
4, Hardening	EDR-vendor exclusion submissions (CrowdStrike cert exclusion, SentinelOne Exclusions Catalog entry, Defender ASR-rule documentation, Huntress partner-channel engagement), end-to-end test matrix, signing pipeline integration (mostly already in place, Section 4)	2
MVP shippable		~14 weeks calendar (15-17 with App Store review variance)
5, macOS broker (later)	Integrate SAP Privileges (Apache-2, Section 13) for the Mac elevation primitive; reuse the approval workflow from Phase 1	+3
6, Path B refactor + AP-compatible elevation (when AP rolls out)	Replace the SendInput injection layer with CreateProcessAsUser-based elevation; add Windows Hello/PIN integration for AP	+4
7, Server-side PAM (Halaas Layer 2) (much later)	Session brokering, JEA constrained PowerShell, approval-gated RDP/SSH, see Section 11	+6-8

What's different from an earlier draft of this estimate

The first internal draft of this Discussion estimated 8-9 weeks single-dev. That estimate was based on a UI-Automation-polling architecture that doesn't actually work against the secure desktop (Section 5 constraint #4 above). The honest revised estimate accounts for:

• ETW-based detection layer is faster to ship than UIA polling (no per-locale matching) but requires upfront learning of the LUA provider's event semantics. Net: similar effort, much more durable.
• The SYSTEM-spawn-onto-WINLOGON-desktop pattern is well-documented but not trivial. Realistic 1.5 weeks (not 0.5).
• EDR-vendor exclusion submissions were uncited folklore in the v1 estimate; the honest answer is "weeks-to-months calendar time" but most of it is wall-clock waiting, not engineering effort. 2 weeks of engineering work to package, document, and submit.
• App Store review is now estimated 1-3 weeks calendar based on category precedent (Section 3).
• Code-signing pipeline is BETTER than the v1 estimate (Azure Trusted Signing, not DigiCert EV; already wired). ~2-4 hours to add a binary, not 1 day.

---

8. What kills this if you're not careful

1. Windows 11 Administrator Protection re-rollout. AP is currently reverted but Microsoft has said it "will roll out at a later date." When it does, our SendInput injection layer will break. Our ETW detection layer survives unchanged (events 15031/15032 are explicitly for AP). Mitigation: Phase 6 is already planned for the elevation-primitive swap; track Microsoft's AP rollout schedule via the Patch My PC writeup and Windows Insider channels.

2. EDR vendor flagging. A SYSTEM-context binary that does SendInput from a secure-desktop child looks identical to credential theft. Mitigations:

   • CrowdStrike Falcon: cert-based exclusion using our Azure Trusted Signing cert chain. Propagation up to ~40 min. (CrowdStrike exclusions)
   • SentinelOne: submit to the public Exclusions Catalog, CyberFOX has entries in there for Password Boss, precedent exists. (SentinelOne Exclusions)
   • Microsoft Defender ASR: several ASR rules don't honor standard AV exclusions and require per-rule chain-pattern exclusions; persistence via WMI event subscription is "not supported for exclusions." A SYSTEM-context broker that hooks consent.exe will collide with at least the "Block process creations originating from PSExec and WMI" and "Block credential stealing from LSASS" rules. (Microsoft Defender ASR rules reference)
   • Huntress: no public ISV-onboarding doc exists. Need to engage the Huntress partner channel directly. Budget 2-4 weeks for negotiation.
   • Total realistic timeline: 2 weeks of engineering work to package, document and submit; 2-8 weeks calendar of waiting for each vendor's allowlist confirmation.

3. SendInput continuing to work post CVE-2026-20824. Microsoft is squeezing the input-injection surface. The January 2026 hardening did NOT name SYSTEM-context injection on the secure desktop as impacted, but the trajectory is clear. Mitigation: Phase 6 (Path B / token-based elevation) is the long-term answer.

4. Non-English Windows. ETW event IDs are language-invariant (huge improvement over UI Automation polling). Some risk remains in the user-mode dialog process (it has to identify "the executable that's about to elevate" and that name comes from UACElevateFileID field in event 16001-16011, which is also language-invariant). Net: much lower risk than the UIA-polling architecture.

5. Audit-log volume. A noisy endpoint can fire 50+ UAC prompts/hour. At 10K endpoints that's 500K rows/hour worst-case. PostgreSQL handles it but agent_logs should be partitioned from day one. Reuse the existing partitioning pattern if one exists; if not, add it.

6. Liability and approval rubber-stamping. PAM means "the MSP can grant admin." If a tech approves a malicious request, the MSP gets the blame. Mitigations:

   • MFA on the approve action itself (existing middleware)
   • 4-eye approval mode (one extra table, optional per-org policy)
   • Per-tenant maximum approval rate limit (reuse the notificationThrottle pattern from feat(alerts): per-channel notification throttle with sliding-window cap #796)
   • Anomaly detection: alert when approve-rate jumps 3σ above the rolling 30-day baseline
   • Approver fatigue is real and called out in Halaas Section 2.3. Design the UI to make rubber-stamping uncomfortable (show requester history, request reason, executable details prominently).
   • Insurance and contractual implications. This functionality may need disclosure on the MSP's E&O coverage and may need new carve-outs in MSP-customer SLAs. Worth flagging at product launch.

7. N-able N-Central deadlock interaction (Section 5). Any customer running N-Central + Breeze PAM concurrently could hit the documented 4-5 minute consent.exe hang. Mitigation: test against N-Central in our integration matrix; document the interaction in the Breeze KB.

8. Mobile push reliability. AutoElevate's 3.0/5 iOS rating tells the story. Don't ship until push delivery is observed-reliable across both APNs and FCM in real conditions for at least 2 weeks. Include "send test notification" button in tech onboarding.

---

9. Strategic case for Breeze

• Closes a real competitive gap. No major RMM ships endpoint PAM today. NinjaOne's most recent partner-facing window for their own PAM has slipped from "2-5 months" (April 2026) to "this year or 2027." Breeze can ship first.
• "No separate PAM tool needed" is the marketing line. Customers save $250-$650/month per tenant on the eliminated PAM SKU.
• Bundled MSP-grade PAM is a moat. AutoElevate sells exclusively to MSPs, integrates with the same RMMs Breeze targets, and is openly complained about (mobile app, rule engine, support quality). All weaknesses we can lean into.
• Aligned with existing security narrative. Breeze already has DNS Security ([UI] DNS Security feature has no web frontend #828/feat(dns-security): scaffold web UI — sidebar entry, /dns-security page, Integrations tab #847), Sensitive Data scanning, Patch Management, the Huntress integration story. Endpoint PAM completes the security suite.
• Pricing implications. Even at a modest $1/endpoint/month add-on, 10 pilot MSPs at 200 endpoints each is $24K/year of recurring net-new revenue. Compares well to the engineering cost.
• No PAM vendor has shipped AP-compatible code yet. First-to-AP is a separate competitive window 6-18 months out. We can architect for it now.

---

10. Open questions for the maintainer

Before code: same as Discussion #854.

Q1. Does endpoint PAM fit Breeze's product scope? Real engineering commitment (~14 calendar weeks), AV-vendor and code-signing exposure, changes the conversation about what Breeze is. If "out of scope," I'd rather know now.

Q2. Where does the Windows broker binary live? Three options:

• (a) Inside breeze-agent as another goroutine/package, fast to ship, harder to AV-isolate
• (b) New breeze-elevation-broker binary, separate WiX install, clean separation, cleaner AV story, ~2 hours additional CI work (Azure Trusted Signing handles it)
• (c) Inside breeze-watchdog, already SYSTEM-context but conflates concerns

Recommend (b) for AV isolation; willing to do (a) for speed.

Q3. Mobile app strategy: PWA-only, PWA + Capacitor wrappers, or full native?

• PWA-only: fastest to ship, weakest lock-screen UX especially on iOS
• PWA + Capacitor: 90% code reuse, native push and biometric work properly
• Full native: maximum polish, double the engineering

Recommend PWA in Phase 1 then Capacitor wrappers in Phase 3.

Q4. Windows broker path: Section 5 lays out the ETW + SYSTEM-spawn + SendInput recommendation. Open questions:

• Are you OK with the SYSTEM-spawn-onto-WINLOGON-desktop pattern? (Documented but unusual.)
• Are you OK with the dormant-admin-account approach (~breeze_elev with rotated password) vs adding the requesting user to Administrators?
• Should we prepare a Path B / AP-compatible variant alongside MVP, or wait until AP forces our hand?

Q5. Server-side PAM (Halaas Layer 2, see Section 11), explicit Phase 7 or out of scope?

Q6. Pricing model in mind? Whether this is in-bundle (Pro tier upgrade) or a paid add-on changes how aggressive the marketing investment should be.

---

11. Two distinct PAM layers worth eventually shipping

Layer 1, Endpoint UAC elevation (this Discussion, MVP)

"Sarah wants to install QuickBooks on her workstation." End users at standard-account workstations who occasionally need admin to do legitimate work. AutoElevate, Admin By Request, Idemeum EPM, ThreatLocker Elevation. Agent on every endpoint intercepts UAC. Day-to-day operational record. High volume.

This is what this Discussion is proposing.

Layer 2, Server-side session brokering (separate, much later)

"An admin needs to RDP into the file server to fix a permission." Sysadmins doing infrastructure work, not end users.

Session gateway (Apache Guacamole) brokers RDP/SSH/VNC, identity federated through the directory + MFA, sessions are recorded, operations on AD are constrained via PowerShell Just Enough Administration (JEA).

Reference: Jacob Halaas, "Open-Source Privileged Access Management: A Reference Architecture for Constrained Administrative Delegation in Small and Mid-Size Enterprise Environments," Zenodo DOI 10.5281/zenodo.19639352, April 2026, CC-BY-4.0. 22-page reference architecture documenting an open-source PAM stack (Apache Guacamole + n8n + nginx + Python + pypsrp + PowerShell JEA + gMSA + Group Policy) that replaced a commercial PAM product at a 50-500 user organization. ~20 architect-hours initial, 2-4 admin-hours/month ongoing.

If Breeze ever expands the PAM story to "secure server administration," the Halaas paper is a near-turnkey blueprint. Layer 1 is scoped to this Discussion; Layer 2 exists and is worth knowing about.

---

12. Competitive landscape (verified, April-May 2026)

CyberFOX AutoElevate, the incumbent to beat

• Independent vendor (NOT owned by N-able). Took a 9-figure Level Equity raise on 2026-02-02 with Radian Capital and the founders. Sources: CyberFOX press release.
• Architecture (verified inferentially from public docs + Microsoft's documented secure-desktop constraints): Windows service spawns user-context AEUACAgent.exe per logged-in user; user-context process polls for consent.exe via UI Automation (or, more likely given the secure-desktop constraint, the LUA ETW provider, CyberFOX doesn't publicly document this). Three elevation modes: dormant local admin account ~0000AEAdmin (default, rotated password, milliseconds-window add-to-admin then demote, credential injection into consent.exe by a SYSTEM-context child on WINSTA0\WINLOGON), temporary user-promotion, or SYSTEM-token re-launch. Source: Elevation Types KB, E-N Computers partner writeup.
• Also ships a minifilter kernel driver for the Blocker (LOTL detection) feature, not for elevation. Source: Managing Blocker Rules.
• Rule scopes: All Companies → Whole Company → Whole Location → Computer. Computer-level wins.
• Offline behavior: cached rules in protected registry, work without internet.
• macOS: Early Access Phase 1, macOS 14+, gated. No Linux.
• Mobile app: AutoElevate Notify on iOS + Android. 3.0/5 on iOS App Store with recurring complaints about forced logouts mid-session, missing biometric, inconsistent push.
• Pricing: $2.10-$2.20/endpoint/month, 1-year minimum (verified April 2026 quote).
• Has not published Administrator Protection compatibility statement. Agent changelog through v2.10.27 (2025-09-09) makes no mention of AP, 24H2, or 25H2.

ThreatLocker Elevation Control

• Bundle-only (cannot buy elevation standalone since May 2024). Full Unified Bundle includes Allowlisting, Ringfencing, Elevation, Storage Control, Network Control.
• ~$3-4/endpoint/month for full bundle. Vendr data: $42-49/license/year.
• 4.8/5 on G2. ThreatLocker Admin iOS app (id 1595136398) live in App Store.
• MSP fit: very popular, but bundle pricing prices it out for MSPs who only want elevation.

Admin By Request

• Danish vendor (Fasttrack Software).
• Free tier: 25 EPM endpoints + 10 servers + 25 SRA licenses, lifetime free, all features.
• Mobile app with Apple Watch + 3D Touch approval. AI auto-approval for low-risk requests.
• Cross-platform: Windows + macOS + Linux.
• Lacks MSP multi-tenant model.

Idemeum

• Full Platform: $2.00/device/mo monthly, $1.60 yearly. Includes elevation + allowlisting + Cloud LAPS + Entra ID JIT.
• JIT-only: $50/tech/mo monthly, $40/tech/mo yearly.
• Broader than just elevation.

Evo Security

Austin TX-based, independent, founded 2018. $6M Series A led by TechOperators in July 2024 ($15.4M total raised). Sources: PRNewswire, Crunchbase.

Scope broader than AutoElevate. Bundles six IAM/PAM capabilities into one MSP multi-tenant platform: MFA, SSO (SAML), managed RADIUS, Help Desk Verification, Technician Elevation, End User Elevation.

• Technician Elevation: JIT admin for MSP techs into customer endpoints + Microsoft Entra, with password rotation. (Technician Elevation page)
• End User Elevation: Launched June 2025, GA July 2025. Standard-user least privilege with AI-enhanced JIT elevation. Runs elevation sessions in Microsoft Secure Desktop. AI summarizes the user's intent in the approval prompt. Sources: End User Elevation page, MSSP Alert.
• Mobile app: Evo Authenticator (id 1441463618, in App Store since 2018). v5.1.0 (July 2025) added end-user elevation support. Combined MFA + elevation approval in one app.
• OS support: MFA across Windows/Mac/Linux. Technician Elevation Windows + Mac. End User Elevation Windows-only.
• Pricing: Not public.

Two specific design choices worth borrowing into Breeze:

1. Secure Desktop is the right architecture, the same isolated desktop UAC itself uses. Credential-grabbing rootkits on the user's normal desktop can't see or replay the approval. Confirmed feasible by Microsoft documentation; the SYSTEM-spawn-onto-WINLOGON pattern in Section 5 is exactly this.
2. AI-summarized request reasons ("user is trying to install Adobe Reader 24, signed by Adobe Inc., from official source") read by the tech on the phone before approving is a UX win and an audit improvement. LLM call is cheap; gates a high-stakes decision. Phase 2 candidate.

Why Breeze wins this category

Bundled with the RMM, no separate vendor relationship, no separate billing, no per-endpoint surcharge for the MSP (if priced as a tier upgrade), the rule engine + audit + mobile-app pieces inherit the polish of the rest of the product. The two big incumbents (AutoElevate and ThreatLocker) sell exclusively to MSPs and the smaller incumbents don't have a strong MSP channel. There's an actual gap.

---

13. Open-source building blocks (verified)

Surveyed GitHub for components Breeze could adopt or borrow from. The Windows broker work has only partial OSS leverage, most of the hard parts are still greenfield.

Windows (broker)

MakeMeAdmin (pseymour), MEDIUM fit (~3-5 day savings)

• URL: https://github.com/pseymour/MakeMeAdmin
• License: GPL-3.0-or-later (confirmed in LICENSE). GPL-3-or-later → AGPL-3 is forward-compatible per GPLv3 §13. No CLA.
• Last release: v2.4.1, November 14 2025, actively maintained
• Stars: 509, language: C# on .NET Framework 4.8 (not .NET 8, port required if we want modern runtime)
• What it gives us: NetLocalGroupAddMembers/RemoveMembers P/Invoke wrappers (well-tested in production 15 years), the SYSTEM-service skeleton + ProjectInstaller boilerplate, DPAPI-encrypted state persistence pattern, session-change/logoff revocation handlers.
• What it does NOT give us: UAC interception, consent.exe credential injection, approval workflow, dormant admin account with rotated password (MakeMeAdmin elevates the user themselves), rule engine, multi-tenant model, mobile app, cloud control plane, audit pipeline.
• Honest verdict: ~3-5 days saved on Win32 group-manipulation plumbing. The 80% of the broker work (Section 5) gets zero help from MakeMeAdmin.

multiOTP Credential Provider, HIGH fit (if Path C ever pursued)

• URL: https://github.com/multiOTP/multiOTPCredentialProvider
• License: Apache-2.0
• Last release: v5.10.2.2, April 4 2026, very active
• Stars: 324, language: C++/PHP
• Production-quality Windows v2 Credential Provider DLL. Cleanest template if we ever go to Path C.
• Verdict: bookmark for Phase 6, not MVP.

privacyIDEA Credential Provider, HIGH fit (architecturally instructive)

• URL: https://github.com/privacyidea/privacyidea-credential-provider
• License: Apache-2.0
• Last release: v3.8.0.0, Feb 27 2026
• Modular split: CppClient (REST to backend), CredentialProvider (Windows COM), CredentialProviderFilter. Exactly the right shape for broker-calls-home-for-approval.
• Verdict: study the architecture, don't necessarily fork.

UACME, explicitly excluded

• URL: https://github.com/hfiref0x/UACME
• Catalog of UAC bypass exploits, not a legitimate building block. Using anything from this repo puts Breeze on every EDR's blocklist. Mentioned only to be ruled out.

macOS (broker)

SAP Privileges, HIGH fit, recommended for Phase 5

• URL: https://github.com/SAP/macOS-enterprise-privileges
• License: Apache-2.0 (best-case for borrowing)
• Last release: v2.5.3, May 15 2026, very active
• Stars: 2.0k, language: Objective-C (96.7%)
• The de-facto macOS open-source admin-elevation tool. Adds/removes user from admin group on a timer; Touch ID and Smart Card/PIV support; MDM-manageable.
• Verdict: fork or integrate for Phase 5. Saves most of the macOS-broker work (~1-2 weeks).

Apple EvenBetterAuthorizationSample, architectural reference

• URLs: Apple official
• THE reference for macOS helper tools, XPC-mediated privileged helper, LaunchDaemon plist, Touch ID confirmation. Even SAP Privileges follows this pattern.

Adjacent, design knowledge

• James Forshaw (@tyranid) + the book Windows Security Internals (No Starch). Invaluable for understanding Windows authentication / UAC / Administrator Protection internals.
• 0xpat's Malware Development Part 7 (writeup) is the working reference for the SYSTEM-spawn-onto-WINLOGON pattern. Cite for design knowledge; the code is for educational purposes.
• repnz/etw-providers-docs (repo) is the only public source for the Microsoft-Windows-LUA event schema. Will need to test event semantics empirically.
• Microsoft's PsSetCreateProcessNotifyRoutineEx docs are the kernel-driver path if Phase 6+ goes that direction.

Build vs borrow verdict

• Windows endpoint agent: ~3-5 days saved by borrowing MakeMeAdmin's P/Invoke wrappers + service skeleton; the rest (ETW, secure-desktop spawn, SendInput, account management, rule engine, IPC) is greenfield.
• macOS endpoint agent: integrate SAP Privileges. Saves ~1-2 weeks.
• Backend approval workflow: build natively. No useful OSS shortcut.
• Mobile push approval: build natively. No useful OSS shortcut.

Net savings from borrowing well-chosen OSS components: ~1 week off the Section 7 estimate. Final MVP estimate stays at ~14 calendar weeks.

---

14. Confidence assessment (honest, per section)

Section	Confidence	Notes
Strategic case (1, 9, 12)	90%	All pricing verified from prior MSP evaluation; competitor positioning verified from primary sources.
Architecture mapping (4)	85%	Every claim has a file:line citation. Local config cache verified at agent/internal/config/config.go:418-454. WS reverse direction verified at apps/api/src/routes/agentWs.ts:2209,2252 + useEventStream.ts.
Windows broker (5)	75%	ETW-based approach is documented and supported. SYSTEM-spawn-onto-WINLOGON path verified from working reference (0xpat). Remaining risk: SendInput behavior on the secure desktop under hardened 2026 Windows.
Effort estimate (7)	70%	Honest decomposition. App Store review and EDR-vendor exclusion timelines now budgeted. Code-signing is easier than first thought (Azure Trusted Signing already wired).
Mobile / App Store (3, 6)	85%	App Store rejection risk verified LOW, 3 PAM apps already live (AutoElevate Notify, ThreatLocker Admin, BeyondTrust Access Console).
EDR allowlist (8)	65%	CrowdStrike + SentinelOne cert/catalog paths verified. Huntress still unclear (need direct engagement). Negotiation timelines uncited but workable.
AP forward risk (8)	60%	AP reverted as of Dec 2025; not blocker today. ETW LUA provider 15031/15032 is the documented AP-compatible channel. Long-term: elevation primitive (SendInput) will break under AP and Phase 6 is required.
License compatibility (13)	95%	MakeMeAdmin GPL-3-or-later → AGPL-3 direction explicitly permitted per GPLv3 §13. Confirmed no CLA.
OSS leverage (13)	80%	MakeMeAdmin doesn't help with the hard parts. Net savings ~1 week.

Overall confidence in shipping a working MVP in 14 calendar weeks: ~75%. The remaining 25% risk concentrates on (a) SendInput injection working reliably on the secure desktop in 2026's hardened environment, (b) EDR-vendor allowlist negotiation timelines, (c) Admin Protection rollout schedule.

---

15. Prior art

• AutoElevate (CyberFOX): https://www.cyberfox.com/autoelevate-by-cyberfox/
• Admin By Request: https://www.adminbyrequest.com
• ThreatLocker Elevation Control: part of the Unified Bundle
• Idemeum: https://www.idemeum.com
• Evo Security: https://evosecurity.com
• Halaas open-source PAM reference architecture: Zenodo 10.5281/zenodo.19639352, CC-BY-4.0, April 2026, server-side / JEA-based pattern (Layer 2)
• Microsoft Privileged Access Workstations + Enterprise Access Model: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
• Microsoft Just Enough Administration: https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview
• NIST SP 800-207 Zero Trust Architecture: https://doi.org/10.6028/NIST.SP.800-207
• Microsoft Administrator Protection: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/administrator-protection/
• Microsoft-Windows-LUA ETW provider schema: https://github.com/repnz/etw-providers-docs/blob/master/Manifests-Win10-17134/Microsoft-Windows-LUA.xml
• 0xpat secure-desktop research: https://0xpat.github.io/Malware_development_part_7/

---

16. What I'm asking

A direction decision before I write code, same as Discussion #854. Specifically:

1. Yes / no on PAM as a Breeze feature (Q1)
2. If yes: preferred broker placement (Q2)
3. If yes: preferred mobile-app stack (Q3)
4. If yes: confirmation on the ETW + SYSTEM-spawn + SendInput architecture (Q4) or appetite for Path B/C
5. If yes: whether Layer 2 server-side PAM is in or out of scope (Q5)
6. Any pricing-model context that should shape the engineering (Q6)

Happy to prototype on a fork once the direction is set. Estimate to a usable Windows MVP is 14 calendar weeks single-dev with PWA mobile approval working by week 4 and the Windows broker landing in week 12.

[ToddHebebrand]

@bdunncompany — thanks for the depth on this. Direction below, plus a few places where Breeze already has more scaffolding than the public repo reveals.

Q1 — Yes, PAM is in scope. Building the full thing, not an MVP carve-out. Both the end-user UAC-interception flow you've scoped and the tech-initiated JIT-admin flow (request temp admin on a device, agent flips group membership, local timer revokes) belong under the same roof. They share schema, audit chain, approval routing, Brain tool integration, and rule engine.

Q4 — Architecture confirmed. ETW Microsoft-Windows-LUA detection + SYSTEM-spawn-onto-WINSTA0\WINLOGON + SendInput injection is the right primary path. Path B (CreateProcessAsUser token-mixing) is the planned successor when Administrator Protection forces the rewrite — worth prototyping in parallel so we're not caught flat when Microsoft re-rolls AP. Paths C (custom CredentialProvider) and D (kernel minifilter) are correctly out of scope.

One thing to recalibrate on effort. Section 5 budgets ~1.5 weeks for "SYSTEM service skeleton" + "user-mode UI dialog process with named-pipe IPC." That work already exists in Breeze for Session 0 remote desktop — and you've personally already touched the relevant binary in #699 and #755:

• agent/internal/sessionbroker/broker_windows.go — SYSTEM-service-side broker, CreateProcessAsUser with explicit session-ID override (built to handle UAC/lock-screen desktops via OpenInputDesktop(GENERIC_ALL))
• agent/internal/userhelper/ — user-session SYSTEM helper that the broker spawns. Now shipping as a GUI-subsystem breeze-user-helper.exe thanks to your feat(agent,windows): ship GUI-subsystem breeze-user-helper.exe to suppress logon console flash #699, which is exactly the right surface for the user-facing PAM dialog (no logon console flash, native window class)
• agent/internal/ipc/protocol.go + message.go — typed bidirectional IPC over named pipe, with auth_windows.go for SYSTEM-side authentication

The PAM flow is the session-broker pattern with new message types: detection in the service, dialog in breeze-user-helper.exe, approval round-trip over the API + mobile, secure-desktop spawn back in the service. No new binary, no new signing profile.

Q2 — Broker placement: (a) inside breeze-agent. The spawning-helper pattern is already production. Adding a third binary doubles the MSI / signing / auto-update / EDR-exclusion surface for marginal isolation gain when the service is already doing SYSTEM-context process spawning and input injection (remote desktop). Keep it in-agent.

Q3 — Mobile path is settled and further along than visible from outside. We have a native Expo app (RN 0.83, React 19) shipping the approval surface end-to-end. The design brief already names PAM elevation as the second consumer of this surface (built first for MCP step-up). The full-screen takeover ships with: approval_requests table with user-scoped RLS, risk-tier + status enums, expiry job, Expo Push dispatch, countdown ring, mono argument rendering, risk band, biometric-gated approve, deny-with-reason, recursive 5s hold-to-confirm, offline cache, expiry animations.

So no PWA detour, no Capacitor wrappers, no Phase 3 mobile track. Adding a new approval flow_type (uac_intercept) alongside the existing one is days, not weeks. App Store submission is in flight — that 1-3 week calendar window from your Section 3 still applies, but it's submission-only, not build-then-submit.

Application Control integration — already built, by design. The software-policy system (apps/api/src/db/schema/softwarePolicies.ts, softwareInventory.ts, plus the audit chain in software_policy_audit) was designed from the start as the layer PAM would consult. It already supports allowlist | blocklist | audit modes with org/site/device targeting, priority ordering, enforce_mode, catalog/vendor/version/file-hash matching, and remediation options (autoUninstall, gracePeriod, cooldownMinutes). The PAM rule engine plugs straight in:

• Allowlisted software auto-elevates with no human in the loop — no Breeze dialog on the user's desktop, no push to the tech's phone, no manual decision. Audit row records the policy match for compliance, that's it.
• Blocklist-mode policy denies → PAM auto-denies, audit row written
• Audit-mode or no match → falls through to PAM's own rule engine (signer / hash / path / parent process / time-window / user / AD-group from your Section 2.14)

That covers ~half of your match-criteria list at the policy layer with zero new code, and gives us the ThreatLocker Allowlisting + Elevation Control bundle as a single integrated system rather than two SKUs. The competitive line writes itself: "Approve software once at the org level. Users install and elevate it themselves. Forever."

Q5 — Server-side / JEA layer (Halaas Layer 2) is a separate piece of work — the tech audit + constrained-shell story for sysadmins doing infrastructure work. Bookmarked for a future discussion, not blocked by Layer 1.

Q6 — Pricing: bundled into the existing tier, not a per-endpoint add-on. "No separate PAM tool needed" is bigger than the SKU revenue, and simpler pricing supports the in-bundle competitive story.

Schema — please design elevation_requests to carry both flows from day one. At minimum:

• flow_type enum: 'jit_admin' | 'uac_intercept'
• trigger_source enum: 'tech' | 'brain' | 'end_user'
• scope enum: 'admin' | 'specific_command' | 'process_elevation'
• process_metadata jsonb for the UAC-intercept fields (executable path, signer cert, hash, parent process, UACElevateFileID correlation)
• software_policy_match_id FK to record which allowlist/blocklist rule fired the auto-decision (or null for fall-through)
• Rule-scope columns matching your Section 2: device → site → org → partner (Breeze's 4-tenancy-shape RLS supports all four already)

Single audit chain, single Brain tool surface, single expiry path across both flows.

Revised effort, full scope (both flows, Windows + macOS + AP successor prototyped in parallel): ~10-12 calendar weeks single-dev, plus EDR-vendor allowlist calendar wait. Concentrated risk is on (a) ETW LUA subscriber semantics, (b) ~breeze_elev account lifecycle, (c) SendInput-on-secure-desktop reliability under 2026 hardening (CVE-2026-20824 carve-out). The schema + approval-routing + mobile-app + service-helper-IPC + application-control pieces are reuse, not build.

Next step: I'm spinning up a public GitHub Project board now — want to try collaborating there. Tracks will include the schema convergence, Windows broker, macOS broker, software-policy bridge, mobile flow_type extension, and the AP / Path B follow-on as parallel lanes. I'll @ you once it's live; happy to take prototype contributions on a fork once the schema lands.

Status: direction approved on all six questions. Schema convergence + broker prototype is the actual blocking work.

[ToddHebebrand]

Project board is live: PAM — Privileged Access Management

Seeded 15 tracks across Schema, Windows broker, Software-policy bridge, Mobile, macOS broker, AP / Path B, EDR / Ops, Web admin UI, Brain integration, and Docs. Each is tagged with Phase / Surface / Effort / External-blocker so the parallel lanes and calendar-blocked items are filterable.

The schema item is the actual gating piece — once elevation_requests lands carrying both flow_type='jit_admin' and flow_type='uac_intercept' from day one, the Windows broker, mobile extension, and software-policy bridge can all proceed in parallel.

@bdunncompany happy to give you write access if you want to push the broker prototype straight to draft items there, or fork-PR flow if you prefer.

[bdunncompany]

Direction agreed across all six questions. Quick close-the-loop:

Architecture (Q4) — ETW Microsoft-Windows-LUA + SYSTEM-spawn-onto-WINSTA0\WINLOGON + SendInput injection confirmed. Will study agent/internal/sessionbroker/broker_windows.go + userhelper/ + ipc/ patterns before drafting the broker so the new code follows the established surface rather than reinventing it.

Broker placement (Q2) — agreed on (a), inside breeze-agent. Adopted the same call for #860 (A4 supervisor goroutine).

Mobile (Q3) — settled. Adding a flow_type=uac_intercept consumer of the existing native Expo approval surface is the path; the PWA + Capacitor plan in v2 of the draft was over-engineered given the native app already ships.

Schema (Q5 gating item) — will hold on the elevation_requests migration until you/I have aligned on whether to extend approval_requests vs new table. Your write-up named the column shape explicitly (flow_type / trigger_source / scope / process_metadata jsonb / software_policy_match_id FK / 4-tenancy scope columns) — happy to draft the migration on a branch and post for review before any code lands against it. Will engage on the schema track on the project board first to coordinate with anything else queued there.

Application Control bridge — the software_policies schema (apps/api/src/db/schema/softwarePolicies.ts, verified: mode = allowlist/blocklist/audit, rules jsonb with software/vendor/version/catalogId, targeting + priority + enforce_mode + remediationOptions) lines up exactly with what the PAM auto-approve layer needs. The "approve software once at the org level, users install and elevate forever" story is the right competitive line — agreed.

Pricing (Q6) — in-bundle, not per-endpoint, agreed.

Layer 2 (Q5b — Halaas server-side) — bookmarked for separate future discussion as you suggested.

Project board (projects/3) — happy to comment-claim tracks once I refresh my gh token scope to include read:project. Will engage there on the schema and Windows broker lanes once the schema direction is settled.

Thanks for the depth on the disclosure of the existing scaffolding (sessionbroker, userhelper, ipc, native Expo app, software_policies). Each one is days of work that does not need redoing.

[bdunncompany]

Following up on the schema decision before drafting the migration.

Direction: new elevation_requests table, not extending approval_requests. Rationale below; flagging now so we're aligned before any code lands.

Tenancy shape is the deciding factor. approval_requests (apps/api/src/db/schema/approvals.ts) is Shape 6 — user-id scoped via userId, RLS pivots on breeze_current_user_id(). Every existing consumer (mobile-app pending list, MCP step-up gate, helper flow) assumes the approver IS the row's tenancy axis.

PAM elevation_requests carries the column shape you spelled out (flow_type / trigger_source / scope / process_metadata jsonb / software_policy_match_id FK + 4-tenancy device→site→org→partner). The natural pivot is Shape 1 (direct org_id like incidents/incident_evidence in 0073-incident-response.sql) with device_id and site_id as denormalized lookup columns for the rule-engine queries and MSP-level audit. partner_id only if we want partner-axis MSP queries without a join through organizations. The audit subject (the elevated process on a workstation) and the approver (the tech, or the rule engine, or the end-user) are different axes — the approver is no longer the tenancy pivot.

Extending approval_requests to carry both shapes would mean rewriting the RLS policy to no-op for flow_type IN ('jit_admin','uac_intercept') rows, adding ~9 columns to a user-scoped table, and threading a "is this row mine to see?" check into every existing consumer. The new-table path keeps the existing user-scoped surface clean and lets elevation_requests use the same Shape 1 + denormalized lookup-column pattern that incidents already uses.

Cross-flow correlation question. Two viable shapes for single-audit-chain:

• (a) elevation_requests.parent_approval_id uuid REFERENCES approval_requests(id) ON DELETE SET NULL — nullable, populated only when the approval round-trip went through the mobile approval surface (i.e. trigger_source is tech or end_user requiring human approve). The auto-elevate path (software-policy match) leaves it null.
• (b) Physically independent, correlate via event-bus approval.id ↔ elevation.id in the audit chain, with audit.actor_chain carrying both refs.

(a) is simpler to query ("show me the elevations approved by this user this week" is one JOIN). (b) is cleaner if the long-term plan is for non-mobile approval paths (Brain-only auto-approve, software-policy auto-approve) to dominate volume, because (a) leaves parent_approval_id null on most rows.

Leaning (a) but won't commit until you weigh in.

Status side: approval_requests' status enum (pending / approved / denied / expired / reported) is reusable, but PAM also needs at least auto_approved (software-policy match) and revoked (admin pulled the elevation mid-window) — new enum elevation_status covers both flows from day one rather than back-port to the shared one.

Next steps once you confirm the direction:

1. I'll refresh my gh token to include read:project + project and comment-claim the Schema track on projects/3.
2. Draft the 2026-MM-DD-a-elevation-requests.sql migration + Drizzle schema + the matching rls-coverage.integration.test.ts allowlist entry on a fork branch.
3. PR for review with the contract test passing locally; no code wired to it yet.

Any objection to the new-table direction, the audit-chain shape (a vs b), or the separate elevation_status enum, please flag before I cut the migration.

[ToddHebebrand]

Three-thumbs-up across the schema questions, with a couple of additions before you cut the migration.

Decision 1 — new elevation_requests table, Shape 1. Agreed. Your tenancy-axis argument is the right call: approval_requests is Shape 6 because the approver IS the tenancy pivot, and that invariant is load-bearing for every existing consumer (mobile pending list, MCP step-up, helper flow). PAM's audit subject (process on a workstation, scoped device → site → org → partner) is a fundamentally different axis from PAM's approver (tech / Brain / end-user / rule engine). Forcing both shapes into one table would mean the RLS policy carrying conditional pivots based on flow_type, which is the kind of cleverness that breaks badly on the next refactor. Mirror the incidents / incident_evidence pattern from 0073-incident-response.sql: direct org_id with denormalized device_id + site_id lookup columns; partner_id included so we can do MSP-level audit queries without joining through organizations. Add to the relevant allowlist in rls-coverage.integration.test.ts in the same PR.

Decision 2 — audit chain via (a), nullable FK. Agreed. elevation_requests.parent_approval_id uuid REFERENCES approval_requests(id) ON DELETE SET NULL. The null-on-auto-elevate case is the correct model, not a degenerate one — auto-elevations genuinely have no parent approval row to point at. (b) would be cleaner if approval-required paths were the rare case, but they aren't, and a one-JOIN query for "elevations approved by this user this week" is worth far more than the architectural purity of physical independence.

Decision 3 — separate elevation_status enum. Agreed. revoked is genuinely unique to elevation (admin pulled access mid-window; doesn't map onto anything in the approval lifecycle), and auto_approved carries different semantic weight than approved — it never went through a human and shouldn't be displayed identically in audit UI. Forcing both flows through approval_requests.status would be hostile to future readers and to anyone doing analytics on the auto-elevate hit rate.

Two additions before you cut the migration:

1. First-class lifecycle timestamps. Include requested_at, approved_at, expired_at, revoked_at, revoked_by_user_id as proper columns rather than reconstructing from audit_logs. Reconstruction works until someone needs to filter "elevations revoked in the last 24h" in a hot path, at which point we'll either denormalize anyway or pay a JOIN-and-aggregate per row. Start denormalized.

2. software_policy_match_id FK semantics — ON DELETE SET NULL. Deleting a software policy must not orphan the historical elevation row (the elevation actually happened, the row needs to survive), but the FK link should null out so a future report doesn't render a dangling policy ID. Same pattern your direction on Decision 2 follows.

Naming reminder (so you don't burn the -a-/-b- slot ordering by accident): 2026-MM-DD-a-elevation-requests.sql for the table + Shape 1 policies, 2026-MM-DD-b-elevation-requests-rls-allowlist.sql only if there's a separate idempotent allowlist-touching migration. The rls-coverage.integration.test.ts allowlist entry is TypeScript so it lives in the same PR but not as a separate SQL file. CLAUDE.md has the full naming + idempotency rules.

Status: direction approved on all three; cut the migration. Schema PR can land standalone (no app code wired) so we can ratify the shape before the broker prototype starts depending on it.