Imagine your team runs separate staging and production APIs for an order app. You ask a coding agent to reproduce an error when editing an order in staging, then discover that its shell loaded the cloud profile you normally use. Although the task says “staging only,” that profile can still change production.
Before the agent starts, give its tools and keys access to the staging setup it needs, and fill that setup with test data. Use the same connection the agent will use to try an allowed action and a harmless action that should be blocked.
Give the task a specific test environment
For an order app like Parcel, write down the staging account or project, Service ID, branch, and test user. Describe what a successful order edit looks like and list the records the agent may change, since other engineers may be using the same test database.
Give the agent read access while it investigates the error. If the task also calls for a deploy, grant that permission for the chosen staging target. An order edit can be tested without giving the agent access to billing or the ability to create account keys.
Keep a separate process for production releases. The agent can hand off a commit and the results from staging for someone with production access to review.
Check every credential the session can use
Check where the agent can find keys beyond the role you gave it. Look in cloud profiles, local settings, and environment variables. Check connected tools, browser sessions, Git remotes, and package scripts too. A script can load a key that you would miss by looking at the shell alone.
For Parcel on AWS, the team might use a separate staging account or a role limited to staging resources. AWS recommends temporary credentials, least privilege, and regular review of unused access. Check any roles the task identity can pass to another service as part of that review. AWS IAM practices
Start a fresh session with the chosen role and keep production keys out of it. If a tool lets you lock the target, enable that setting. A staging default still leaves a path to production when the tool accepts a different target as an argument.
Check the rights on each connected tool. Even when the shell can only reach staging, a cloud connector in the same chat may still have production access.
Keep staging from reaching real customers
Parcel's staging data should use made-up customers, fake payment methods, and test delivery addresses. Copying a production database could expose personal data through queries, logs, or screenshots even if the agent never changes production.
Check outbound settings as carefully as database access. If the staging API inherits a live email credential or payment URL, a test order could send a real message or reach the live payment system. Decide which integrations should use test mode and which should stay disabled during the task.
Share logs for the failed requests around the time of the error. Remove access tokens, private fields, and connection strings first. The smaller set helps the agent find the error and limits how much unrelated data you share.
For Parcel's order bug, a few synthetic records should be enough to reproduce the behavior. If the error depends on a data shape found in production, recreate that shape with fake values.
Test the boundary without risking production
Set up a test resource to stand in for production. On that resource, pick a harmless action that requires the permission you want to check. Then run the checks with the same tool and key the agent will use.
- Read the staging service and confirm its identity.
- Make a harmless staging change that the task is allowed to deploy.
- Verify the running commit and expected test result.
- Attempt the chosen safe operation on the forbidden test target.
- Save the identity, request, and denial, then remove any temporary grants.
Save the result of the staging deploy and the blocked test action. Those results cover the tool and key you used. Run the checks again if you connect another tool or change what a key can access.
When you remove access, check that the agent can no longer use the grant. Give the task a key that expires soon, so a forgotten session has less time to use it after the work ends.
Decide how the staging result reaches production
Once Parcel's bug is fixed, review the diff and the staging evidence. Name the commit that passed and promote that change through the production workflow. A nearby branch with a green check may contain different code.
Review schema changes, new secrets, and wider network access separately when they affect more than the route the agent edited. If several agent tasks are ready for review, name the exact environment and change in each release record.
Keep a short note with the task that records the identity, target, permitted actions, denial check, and date access ended. The next engineer can compare those details with the current setup before reusing the grant.
Select a staging-only grant on Forte
When you connect the assistant on Forte, choose which projects it can see and whether it can deploy Services or Websites. Select only the staging project and grant only the deploy rights the task needs. Your own role still limits what the assistant can do. Leave cost access off for a staging-only session, because it requires access to all projects. Forte AI connection guide
If the shell already holds a separate CLI token, check its scope alongside the assistant grant. Run the allowed and denied checks through the same connection the agent will use.
For sandbox staging, create a sandbox project or clone an existing sandbox project. Sandbox mode is fixed at creation. Cloning a live project keeps live mode, so its name can say “staging” while its payment calls still use live mode. Forte project environments
Clones copy secrets and GitHub branches. Check any copied keys that let the app call outside services, and change the clone's branch so one push cannot deploy to both environments. Cloned databases start empty, so add the test records the agent needs to edit an order.
Sandbox request bodies are captured by default, and sandbox offers more destructive test controls. Keep real customer data out. Environments bill separately and count toward resource limits. Forte sandbox behavior
Start Parcel's session only after the target and grants pass the checks. When the work ends, disconnect the assistant under Account Settings and remove any temporary access. Use the AI connection guide to review the exact grant before the next staging task.