[KR5] Phase 3 - MVP: Centralize Security Orchestrator
Categories
(Core :: Machine Learning: General, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox148 | --- | fixed |
People
(Reporter: rconcepcion, Assigned: rconcepcion)
References
(Blocks 1 open bug)
Details
(Whiteboard: [genai])
Attachments
(2 files, 1 obsolete file)
The POC (Phase 2) implemented SecurityOrchestrator as per-window instances, where each AI Window creates and manages its own orchestrator and session ledger. This approach was sufficient for demonstrating tool.execution validation within each window's context.
For MVP, a centralized architecture is required to support validation at the inference layer. Centralizing the orchestrator as a singleton enables:
- A single security checkpoint accessible to all consumers (AI Window, MLEngineParent)
- Consistent policy enforcement across tool execution and inference phases
- Unified session ledger management with proper multi-window isolation via
sessionId - Consolidated logging through a single SecurityLogger instance
Location: toolkit/components/ml/security/
Key Changes:
- SecurityOrchestrator - Convert from per-instance to singleton with session-keyed ledgers
- SessionLedger management - Move ownership from AI Window to SecurityOrchestrator, keyed by
sessionId - AI Window integration - Update to call singleton orchestrator with
sessionIdparameter - Policy loading - Load once at singleton initialization (not per-window)
- Session cleanup - Add
cleanupSession(sessionId)for AI Window close
Out of Scope:
- MLEngineParent validation hooks (Phase 2 Part 3 - will use this infrastructure)
- LLM output validation logic (Phase 2 Part 3)
- New policies (Phase 4)
- Performance optimization beyond architecture improvements
Acceptance Criteria:
- Security evaluation requests from any AI Window instance are handled by the centralized orchestrator
- Multiple AI Windows maintain isolated security contexts through
sessionId-keyed ledgers - Closing one AI Window does not affect security state of other open AI Windows
- Policies are loaded once and shared across all sessions
- All security decisions are logged through a single SecurityLogger instance
- Existing xpcshell and browser tests pass with the centralized architecture
| Assignee | ||
Updated•8 months ago
|
| Assignee | ||
Updated•8 months ago
|
| Assignee | ||
Comment 1•8 months ago
|
||
Introduce singleton infrastructure for SecurityOrchestrator:
- Add static getInstance() with lazy async initialization
- Add getSecurityOrchestrator() as the preferred public API
- Deprecate create(sessionId) to wrap getInstance() for backward compatibility
- Existing behavior unchanged; tests pass without modification
Part 2 will introduce session-keyed ledgers and update the API signatures.
| Assignee | ||
Comment 2•8 months ago
|
||
Implement multi-session support for SecurityOrchestrator by replacing the
single implicit ledger with session-keyed ledgers.
Code changes:
- Replace single ledger with session-keyed Map (#sessionLedgers)
- Add registerSession(sessionId) for AI Window initialization
- Add cleanupSession(sessionId) for AI Window teardown
- Add resetForTesting() for automation-only test isolation
- Update evaluate() to require a sessionId parameter
- Update getSessionLedger() to take a sessionId parameter
- Fail closed for unknown sessions with UNKNOWN_SESSION code
Test updates:
- Update all xpcshell tests to use the new sessionId-based API
- Add tests for session lifecycle (register, cleanup, idempotence)
- Add test for unknown-session denial
- Use resetForTesting() in teardown to prevent cross-test state leakage
Each AI Window session now maintains an isolated security ledger, enabling
proper security-context separation when multiple AI Windows are active.
This revision depends on Part 1 (singleton refactor).
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Comment 4•8 months ago
|
||
| bugherder | ||
Updated•7 months ago
|
Description
•