AI Operations Without Unrestricted Production Access

These categories can coexist in one incident. AI can explain a failure and prepare a repair without possessing the credentials or tool access needed to apply that repair to production. Keep production credentials out of the agent’s other shells and connectors too: Unfour MCP policy only governs calls through Unfour MCP.

Create or select a test workspace and verify the actual API host, SSH host/account, database endpoint, and database/schema. Use test data and least-privilege service accounts. A workspace named “test” can still contain a production URL or connection; its label is not network isolation.

• ✓ Workspace type, variable environment, and MCP policy are separate settings. With Auto policy, DEV resolves to full_access, TEST to guarded, and PROD to read_only. An explicit policy overrides that mapping; inspect the effective policy rather than relying on the badge.
• ✓ For evidence collection, start with read_only where the required tools are permitted. It permits supported read operations, including restricted SSH diagnostics; it is not an arbitrary read-only shell. Use independent account privileges to limit database and SSH access.
• ✓ If you need MCP to save or run a Flow in test, choose a policy that permits those actions. Guarded applies confirmation to operations identified by the relevant handlers; it does not mean every write waits for a human. Do not relax production policy to run this workflow.
• ✓ Bound query rows, log time windows, output volume, and request repetition. Review returned logs and data before sharing them with a model; masking cannot identify every secret in arbitrary text.

Consider an illustrative job-processing service: the API is healthy, but test jobs remain pending. First define the expected behavior, such as a known test job reaching its completed state within the team’s normal processing window. A successful health endpoint alone cannot establish that the worker processed the job.

1. 1. Test evidence
2. →
3. 2. Hypothesis
4. →
5. 3. Reviewed test change
6. →
7. 4. Repeat checks
8. →
9. 5. Save Flow
10. →
11. 6. Human handoff

1. 1

   Capture a baseline

   Send the saved GET health/status request through permitted MCP tools. Record the resolved host, status, relevant response fields, time window, and test job identifier. Do not repeatedly submit new jobs just to produce a signal.

2. 2

   Compare server and database evidence

   Read a bounded worker log excerpt and use a focused read-only query to inspect the test job’s state or a small aggregate of pending jobs. Confirm all three resources belong to the same test deployment. Ask AI to distinguish observed facts, hypotheses, and missing evidence; correlation is your investigation, not an automatic Unfour feature.

3. 3

   Propose a falsifiable explanation

   Suppose logs suggest the worker is using an outdated queue setting. Ask for the exact configuration evidence that would confirm this and for a bounded change proposal. Do not infer the root cause solely from a growing pending count; a slow downstream dependency could produce the same symptom.

4. 4

   Review a test change and repeat the checks

   Have an operator review and apply the test configuration change through the normal process. Re-run the same API, log, and database checks with equivalent inputs. Confirm job completion and check for duplicate processing or new errors. Record what remains untested, especially differences in production topology, load, and permissions.

Once the investigation is repeatable, save its stable checks rather than replaying the whole conversation. In this example, build a diagnostic Flow from a saved API status request, a saved SSH Task for bounded worker logs, and a Database query. Keep the restart or configuration repair as a separately reviewed operation so a diagnostic rerun does not repeat a mutation.

1. 1

   Name the inputs and targets

   Declare only the inputs the procedure needs, such as a trusted test job identifier or bounded time window. Select the saved request, SSH Task and explicit SSH connection, and Database connection. Review SQL, catalog/schema, task commands, and input substitution before saving.

2. 2

   Encode the checks you can justify

   Use Condition for a defined comparison of inputs or earlier results. Use Wait Until only when a bounded polling check is appropriate: an API GET/HEAD probe or read-only Database probe, with success/failure conditions and a timeout. Database probes require a read-only connection; SSH is not a Wait Until probe.

3. 3

   Test success and failure paths

   Run in test with known inputs, inspect step outcomes and polling attempts, and deliberately exercise missing resources, a failing condition, and a timeout where practical. Check branch destinations: a Condition choosing a branch is not itself proof of application correctness. A successful run only says the defined steps completed under their configured rules.

Flow editing and execution are free core capabilities. Flow is a local runbook, not an LLM/Agent workflow or a general script runner. API steps reject saved request scripts and multipart bodies; keep an unsuitable existing script in its normal reviewed execution process rather than assuming Flow can run it unchanged.

A Flow belongs to a workspace and refers to saved resources there. A variable environment changes the values used by supported substitutions; it is not a deployment target map. Before adapting a tested procedure, inspect every endpoint and resource binding independently.

For a separate target workspace, prepare the needed resources and a definition whose references resolve there. Review the adapted definition again; changing the workspace or selecting an environment is not automatic promotion of a tested Flow. Existing resource validation can catch missing or changed resources, but cannot prove that a reachable host is the intended one or that several services form an atomic transaction.

For production, ask AI to produce a concrete change package: the evidence and uncertainty, proposed script or Flow definition, exact targets, preconditions, expected effects, checks after execution, and recovery procedure. A reviewer should be able to evaluate the change without reconstructing the chat.

• ✓ Review the saved definition and referenced request, Task, and connection settings together. Record the intended revision, environment, runtime inputs, affected services or rows, and the operator responsible. Re-review if those inputs or dependencies change.
• ✓ For mutations, specify idempotency and partial-failure behavior, a backup or recovery prerequisite where needed, a stop condition, and the exact rollback action. Neither a rollback paragraph nor a cancel button makes a destructive change reversible.
• ✓ Have the authorized operator verify the target and execute through the desktop Flow Run confirmation or the team’s normal script/deployment process. MCP policy is not a universal desktop lock; manual execution remains subject to the operator’s credentials and organizational authorization.
• ✓ Compare the outcome with the predeclared success criteria and retain the relevant run history and change record. If a timeout or cancellation leaves the remote result uncertain, inspect the target before retrying. Cancellation does not undo completed effects.

Other MCP tools have their own risk checks, and full_access can bypass guarded confirmations. Do not infer that every high-risk tool call will prompt. When production policy blocks Flow, keep it in place and use only permitted individual diagnostics, or have an operator provide reviewed evidence.

Unfour provides the runtime tools, user-defined Flow steps, execution checks, and local run history used here. The investigation, choice of success criteria, review, and production handoff remain human-directed. Test results are evidence for a proposal, not certification that it is safe for production.

Automatic conversation-to-Flow generation, business-level validation, environment-aware resource promotion, and unattended safe deployment are not provided by this workflow. Treat them as possible future designs, not released capabilities or a delivery commitment. Flow V1 has no scheduler, webhook triggers, parallel steps, sub-flows, or LLM/Agent nodes.