A coding agent can make a substantial change before a team has agreed how that change should reach production. That gap is where a useful prototype can become an uncomfortable operational responsibility.
The answer is not a longer prompt saying “make it secure”. It is a working setup that limits access, makes important assumptions testable and gives someone responsibility for the release.
These seven guardrails are a recommended baseline for products built with Codex, Claude Code or a similar assistant. They are not a claim about a particular client implementation, a complete security programme or a guarantee that a product is safe.
1. Define the change and the stopping point
Before the agent edits code, describe the user problem, the intended behaviour and what is outside scope. Identify actions that require a separate decision, especially publishing, deleting data, changing billing or altering access.
Put durable project conventions in the repository. Codex supports AGENTS.md instructions for this kind of context. Include the actual build and test commands, the application boundaries and any areas that need specialist review.
Evidence to keep: a short task brief and acceptance criteria. Instructions guide behaviour; they do not enforce a security boundary.
2. Limit what the agent can reach
Give the development task access to the project and services it needs, not every account the organisation owns. Separate read access from write access and keep production authority distinct from ordinary implementation work.
Codex documents sandbox and approval controls. Claude Code documents permissions and their relationship to sandboxing. The exact setup depends on the environment and connected tools, so verify the effective controls rather than assuming a label covers everything.
Evidence to keep: the approved access scope, the configured restrictions and the person responsible for exceptions.
3. Keep secrets and real customer data out of routine development
Use test accounts and representative synthetic data. Keep credentials in appropriate secret storage rather than source files, screenshots, article examples or prompts. Separate development, preview and production credentials.
Inspect what integrations can read and where information is sent. A tool connection can expose data even when the repository itself contains no secrets. Review logs and generated files before sharing a task or publishing an artifact.
If a credential is exposed, follow the provider’s revocation and rotation process. Removing it from the latest file is not enough if it remains usable elsewhere.
Evidence to keep: a data-flow note, secret-scanning results and an owner for credential management.
4. Enforce access and business rules on the server
Do not confuse a hidden control with a protected operation. Account boundaries, roles, subscription entitlements and destructive actions need enforcement at the trusted layer handling the request.
OWASP recommends validating permissions on every request. Make the product’s rules explicit and test them with separate accounts and organisations in a controlled environment.
Use supported identity and payment integrations where appropriate, but still review how the application uses them. Installing a reputable provider does not prove that your own access checks are correct.
Evidence to keep: an access matrix and tests that reject unauthorised operations, not just tests that accept valid ones.
5. Test the failure paths as well as the happy path
A form that succeeds once is a demonstration. A production workflow also needs to handle invalid input, expired sessions, duplicate requests and unavailable dependencies.
Keep automated checks for important behaviour, then review the actual user journey. Ask someone to use a narrow screen, navigate with a keyboard and recover from a validation error. Record checks that were not performed rather than implying complete coverage.
The agent that wrote the code can help test it, but human review and independently defined acceptance criteria remain important. Passing a test built around the same mistaken assumption does not resolve the mistake.
Evidence to keep: test results, review notes and a list of known limitations.
6. Release through a recoverable process
Use a preview or staging environment, review the diff and identify the exact version being released. Require the appropriate approval before changing production. Keep a known-good version and a documented response to a failed deployment.
Database changes need particular care. Reverting application code does not necessarily reverse a schema migration or restore deleted records. Plan compatibility, backup and recovery before applying the change.
Evidence to keep: the release reference, approval, rollback plan and a tested recovery procedure proportionate to the product.
7. Give the running product an owner
After launch, someone needs to receive meaningful alerts, review recurring failures, maintain dependencies and respond when a provider changes behaviour. Define what is monitored and what response is included.
Set appropriate limits for expensive operations and third-party usage. An AI feature that works well for one request can behave very differently when exposed to repeated automated use.
Evidence to keep: an operational checklist, alert destinations, cost controls and a named decision-maker. A dashboard nobody checks is not an operating model.
These guardrails make speed more useful because the team can understand and safely repeat the process. For a concrete example of the review itself, see our worked production-audit example. For implementation and ongoing ownership, explore app development and managed website hosting.
