Skip to content

Week 9: Production Practices

From "it worked once" to "a team can trust it."

This Week's Question

How do you make an OpenCode setup safe enough to share?

By the end, learners can:

  1. Harden agent permissions.
  2. Manage cost and context.
  3. Write eval prompts.
  4. Version agents, skills, and commands.
  5. Review secrets and MCP supply-chain risk.

The Production Shift

Personal agent:

  • Fast to change.
  • Few guardrails.
  • One user understands the risk.

Team agent:

  • Reviewed changes.
  • Narrow permissions.
  • Repeatable evals.
  • Clear ownership.

Speaker note: The goal is not bureaucracy. The goal is trust.

Principle 1: Deny-by-Default

Start with no tools.

Add only what the role needs.

Agent Likely Tools Deny
Security reviewer read, glob, grep edit, bash
Test runner read, bash edit
Docs writer read, grep, edit bash

Speaker note: If you cannot explain a permission, remove it or set it to ask.

Permission Risk Ladder

Low risk:

  • read
  • glob
  • grep

Medium risk:

  • webfetch
  • skill
  • task

High risk:

  • edit
  • bash

Very high risk:

  • MCP tools touching GitHub, databases, cloud, browser, or internal systems.

Demo: Permission Hardening

Before:

permissions:
  read: allow
  edit: allow
  bash: allow
  webfetch: allow

After:

permissions:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash: deny
  webfetch: ask

Speaker note: Tie every allowed tool to the agent's one job.

Principle 2: Context Is a Budget

Bad prompt:

Read the whole repo and tell me what looks risky.

Better prompt:

Review `.opencode/agents/security-reviewer.md` only.
Check permissions and MCP access.
Return high-risk issues only.

Smaller context is usually more reliable.

Cost Habits

  1. Scope paths tightly.
  2. Use smaller models for mechanical work.
  3. Summarize logs before hand-off.
  4. Cap output shape.
  5. Stop repeated failed loops.

Speaker note: Cost control is also quality control. Noisy context makes bad answers more likely.

Principle 3: Evals Are Regression Tests

An eval checks whether an agent behaves correctly after a change.

Each eval needs:

  1. Scenario.
  2. Input.
  3. Expected behavior.
  4. Failure conditions.
  5. PASS/FAIL output.

Five Evals Per Production Agent

  1. Happy path.
  2. Permission boundary.
  3. Bad input.
  4. Security case.
  5. Cost/context case.

Speaker note: These are not perfect automated tests yet. They are repeatable checks that make behavior discussable.

Eval Example

Scenario:
A config gives a security reviewer `bash: allow`.

Expected behavior:
Flag this as too broad. Recommend `bash: deny` or `ask`.

Failure conditions:
Fail if the agent says the config is safe.
Fail if it edits files during review.

Principle 4: Version Prompt Assets

Version:

  • Shared .opencode/ config.
  • Agent files.
  • Skill files.
  • Slash commands.
  • Eval prompts and fixtures.
  • Permission rationale docs.

Do not version secrets or local provider keys.

Prompt PRs Need Context

Good PR description:

Change: Tighten release-notes permissions.
Why: Agent was loading unrelated source files.
Risk: May miss notes outside the diff.
Evals: happy-path, large-diff, no-changes.

Bad PR description:

Tweaked prompt.

Principle 5: Team Adoption Starts Small

Rollout path:

  1. Pick one safe workflow.
  2. Create one narrow shared agent.
  3. Add three to five evals.
  4. Have two teammates try it.
  5. Fix failures.
  6. Expand only after trust grows.

Team Norms

Agree before scaling:

  1. Agents do not merge PRs without human review.
  2. Agents do not receive production secrets in prompts.
  3. High-risk tools default to ask.
  4. Shared prompt changes get reviewed.
  5. Evals run before approved agents change.

Secrets Rule

Never paste secrets into prompts.

Secrets include:

  • API keys.
  • OAuth tokens.
  • SSH private keys.
  • Database URLs with credentials.
  • .env values.
  • Customer personal data.

If a secret touches a prompt, rotate it.

Safer Debugging Prompt

Bad:

Here is my `.env`. Why does auth fail?

Better:

Auth fails with `401 invalid_client`.
The app reads `CLIENT_ID` and `CLIENT_SECRET` from env vars.
I verified both are set.
Review the code path. Do not ask for secret values.

MCP Is Supply Chain

An MCP server is executable code plus credentials plus agent reach.

Review before adding:

  1. Maintainer.
  2. Source.
  3. Version pinning.
  4. Credential scope.
  5. Read/write access.
  6. Data sent to third parties.
  7. Removal plan.

Safer MCP Defaults

  1. Prefer official or reviewed servers.
  2. Pin versions.
  3. Use read-only tokens where possible.
  4. Scope tokens to one repo or project.
  5. Avoid production database access.
  6. Require review for new servers.
  7. Document what each server can access.

Lab 9.1

Write five evals for one Week 6 agent.

Deliverables:

  1. Agent chosen.
  2. Five eval prompts.
  3. Run notes.
  4. One fix based on a failed or weak eval.
  5. Short summary of what changed.

Lab 9.2

Security review a peer config.

Look for:

  1. Overbroad permissions.
  2. Secret handling risks.
  3. MCP supply-chain risks.
  4. Missing evals.
  5. Missing ownership or review process.

Key Takeaways

Production OpenCode work is:

  • Scoped.
  • Permissioned.
  • Evaluated.
  • Versioned.
  • Reviewed.
  • Secret-safe.

Next week: capstone PR review pipeline.