AI operations

The AI DevOps Engineer is a tool-using assistant with a bounded, typed catalog. It proposes; identity, entitlements, deterministic policy and human approval authorize.

Proposal to worker

user message -> tenant-scoped context + redaction -> model
       ^                                      |
       |                                      v
       |                         typed Zod tool proposal
       |                                      |
       |                    server permission + entitlement + policy
       |                                      |
       |                 risk 0: run | risk 1-3: approval record
       |                                      |
       +<------------ worker result + verification + audit

Tool results are persisted as proposals and executions. Risk 0 reads can run automatically; risk 1 needs confirmation; risk 2 needs explicit approval; risk 3 additionally needs an elevated role, typed target confirmation, second confirmation, written reason, idempotency guard and fresh risk revalidation. A model cannot approve its own call, change permissions, use unrestricted shell or claim success.

Execution state is proposed -> awaiting_approval -> approved -> queued -> running -> succeeded | failed | partially_succeeded | cancelled | rollback_available -> rolling_back -> rolled_back. succeeded is recorded only after the worker verifies the result.

The model context excludes secrets. Logs, repository files, provider metadata and other ingested data are treated as untrusted data, not instructions. The API validates all tool parameters and re-checks tenant scope, limits and approvals.

With AI_PROVIDER=mock, responses and tool results are deterministic and local. AI_PROVIDER=moonshot requires the configured Moonshot endpoint, key and model. AI_PROVIDER=gemini uses the Gemini generateContent API and requires GEMINI_API_KEY.

The assistant is deliberately scope-limited to the Devopsify website and application. A server-side scope gate rejects unrelated requests before the provider is called, and the model receives the same scope rule as a defense in depth. This changes model availability, not authorization rules.