16 lines
1.1 KiB
Markdown
16 lines
1.1 KiB
Markdown
# 2025-10-27 — Orchestrator operator scope & audit metadata
|
|
|
|
## Summary
|
|
|
|
- Introduced the `orch:operate` scope and `Orch.Operator` role in Authority to unlock Orchestrator control actions while keeping read-only access under `Orch.Viewer`.
|
|
- Authority now enforces `operator_reason` and `operator_ticket` parameters on `/token` requests that include `orch:operate`; missing values yield `invalid_request` and no token is issued.
|
|
- Client credentials audit events capture both fields (`request.reason`, `request.ticket`), giving SecOps traceability for every control action.
|
|
|
|
## Next steps
|
|
|
|
| Team | Follow-up | Target |
|
|
|------|-----------|--------|
|
|
| Console Guild | Wire UI control panels to request `operator_reason`/`operator_ticket` when exchanging tokens for orchestrator actions. | Sprint 23 stand-up |
|
|
| CLI Guild | Add flags to `stella orch` subcommands to pass reason/ticket metadata before enabling mutations. | Sprint 23 stand-up |
|
|
| Orchestrator Service | Enforce presence of `X-Stella-Reason`/`X-Stella-Ticket` (or equivalent metadata) on mutate endpoints and align audit logging. | ORCH-SVC-33-001 implementation |
|