Objective
Implement the source-side evidence boundary required for one future operator-triggered staging investigation.
This is Phase 3, Iteration 1 of the SRE Platform roadmap. The goal is to make a strictly bounded set of staging evidence available without granting an investigator broad Kubernetes, Prometheus, log, GitOps, network, or write access.
The resulting interface will later be consumed by the AI Operations Platform and a replaceable read-only investigator. This Issue does not authorize an AI investigation itself.
Required Boundary
The implementation must provide an enforceable, least-privilege evidence interface for only the approved staging target.
Approved evidence categories:
- Kubernetes workload and rollout state;
- approved namespace-scoped events and pod status;
- bounded container logs;
- approved parameterized Prometheus queries;
- approved GitOps repository paths and deployment revision metadata.
The interface must enforce restrictions below the investigator. Prompt instructions, an unrestricted Kubernetes credential, unrestricted PromQL, broad log access, or post-processing of unrestricted evidence are not acceptable controls.
Scope
- Define and implement an explicit allowlist for resources, namespaces, names or labels where applicable, read operations, Prometheus query templates, GitOps paths, time windows, output sizes, and request limits.
- Use a dedicated identity with no mutation permissions.
- Prevent direct investigator access to broad Kubernetes, Prometheus, or log endpoints.
- Use private authenticated transport; do not introduce public ingress.
- Produce stable, sanitized evidence identifiers and an auditable request/result record.
- Define bounded failure behavior: deny ambiguous, out-of-scope, oversized, expired, malformed, or unavailable requests.
- Add focused repository documentation, automated tests, and negative tests proving that prohibited writes and broader reads are denied.
- Keep the interface compatible with the existing AI Operations Platform request/result and human-review model, without moving task ownership into this repository.
Explicitly Out of Scope
- Running HolmesGPT or any other AI investigation.
- Scheduler operation or scheduled health checks.
- PagerDuty-triggered AI workflows or PagerDuty changes.
- Automated remediation, Kubernetes mutation, Git writes, incident resolution, or promotion decisions.
- Production access or production validation.
- Broad cluster-admin, namespace-wide investigator, unrestricted Prometheus, unrestricted log, or public network access.
- Terraform, capacity, budget, chart-version, or public-exposure changes unless separately approved.
Delivery Approach
This Issue proceeds in two approval-gated stages.
Pass A — Read-only architecture and implementation plan
Inspect the current sre-platform and ai-operations-platform implementations, their public architecture/roadmap/validation records, and the existing AI Operations control-plane contract.
Produce a concrete recommendation for:
- the smallest enforceable interface design;
- repository ownership boundaries;
- identity, authorization, and private-transport model;
- exact allowlist and evidence envelope;
- audit and negative-test strategy;
- focused implementation slices and explicit live approvals.
Do not change repository files or live systems during Pass A.
Pass B — Focused repository implementation
After explicit approval of the Pass A plan, implement the agreed repository-side interface in focused pull requests. Any cloud, IAM, secret, network, Kubernetes, GitOps, model, or cross-project mutation requires separate explicit authorization with its exact target, cost impact, validation, stop conditions, and rollback path.
Acceptance Criteria
- The approved staging investigation can retrieve only its required evidence.
- Every broader namespace, resource, query, path, time range, output size, write verb, and unauthenticated request fails closed.
- The investigator receives no direct broad infrastructure credential.
- Evidence requests and returned packages are attributable to one approved target, revision, and time window.
- No secret value, project identifier, endpoint, identity, or unsafe runtime data appears in public documentation, commits, pull requests, tests, logs, or evidence.
- The interface remains independent of PagerDuty and SRE-owned recovery.
- No production, automated-remediation, Scheduler, or AI-investigation completion claim is added.
Relates to the completed staging SRE delivery and PagerDuty incident-response milestone.
Objective
Implement the source-side evidence boundary required for one future operator-triggered staging investigation.
This is Phase 3, Iteration 1 of the SRE Platform roadmap. The goal is to make a strictly bounded set of staging evidence available without granting an investigator broad Kubernetes, Prometheus, log, GitOps, network, or write access.
The resulting interface will later be consumed by the AI Operations Platform and a replaceable read-only investigator. This Issue does not authorize an AI investigation itself.
Required Boundary
The implementation must provide an enforceable, least-privilege evidence interface for only the approved staging target.
Approved evidence categories:
The interface must enforce restrictions below the investigator. Prompt instructions, an unrestricted Kubernetes credential, unrestricted PromQL, broad log access, or post-processing of unrestricted evidence are not acceptable controls.
Scope
Explicitly Out of Scope
Delivery Approach
This Issue proceeds in two approval-gated stages.
Pass A — Read-only architecture and implementation plan
Inspect the current
sre-platformandai-operations-platformimplementations, their public architecture/roadmap/validation records, and the existing AI Operations control-plane contract.Produce a concrete recommendation for:
Do not change repository files or live systems during Pass A.
Pass B — Focused repository implementation
After explicit approval of the Pass A plan, implement the agreed repository-side interface in focused pull requests. Any cloud, IAM, secret, network, Kubernetes, GitOps, model, or cross-project mutation requires separate explicit authorization with its exact target, cost impact, validation, stop conditions, and rollback path.
Acceptance Criteria
Relates to the completed staging SRE delivery and PagerDuty incident-response milestone.