Your team asks Claude Code to fix a bug in the API you run on AWS. When the tests pass, Claude offers to deploy the fix. Before saying yes, check which AWS account its shell can reach and what it has permission to change.
An AWS admin credential can do much more than release one API. If that credential is available in the agent's shell, a mistaken command can affect unrelated services, data, or access settings. The risk comes from the access you provide as well as the work you ask the model to do.
Give the agent a specific production job, such as reading deployment results or releasing an approved change, and give its tools only the access that job needs. Review changes to the cloud setup separately.
Decide what you want the agent to do
Consider a team with a staging API and a production API. The team wants Claude to fix a failed staging release, then prepare the same change for production. This is an example workflow, not a claim that any model will always follow it correctly.
For the staging repair, the agent needs to read the build result, inspect safe logs, edit code, and run tests. It may also need to trigger the existing staging deployment. None of those tasks requires permission to delete the production database or change the account's administrators.
Before starting the session, write down which app and environment the agent can touch and what it may do there. List the decisions a person needs to review, such as changing production access or removing a database column. You can check the tool setup against those specifics. A request to “help with infrastructure” gives you too little to work with.
Keep production credentials in the release pipeline
If your team already has a reliable release pipeline, let Claude prepare the pull request and have a reviewer check the code and database changes. The pipeline can deploy the approved commit with its own credentials.
In that setup, the agent does not need the production deploy access in its interactive shell. It still contributes to the production change, but the release process decides which revision goes live.
Direct deployment can also be appropriate for a specific task. In that case, use a credential limited to that work. On AWS, this usually means a role with only the required permissions and temporary credentials. Check which resources it can affect and whether it can pass a more powerful role to another service. AWS IAM guidance
Check which credentials the process can use before relying on a narrow role. An old admin key in the environment can give the session access beyond the limits you set for the new role.
Check the agent's tools as well as the cloud role
Claude Code has rules that control tool and command access. Review those rules, including broad allowances and the permission mode in use. Keep commands that your team considers high risk behind the review your team needs. Claude Code permissions
Check the agent's tool rules and the AWS policy because they act at different points. A tool rule can stop the command before it runs. If the command does run, AWS can still reject the operation when the session's credential lacks permission.
For example, a command may be allowed to run in the shell and still receive an AWS access-denied response. That denial is useful evidence that the access has a limit. It should prompt the agent to explain the missing access, rather than look for another powerful credential as a shortcut.
Rehearse the boundary away from real production
Before allowing this workflow during an incident, try it in an isolated test setup. Give the test identity the staging access you intend to use. Ask it to release a harmless reviewed change and confirm which commit is running afterward.
Then check a denied action against a harmless test resource that represents production. Choose the test carefully so an unexpected grant cannot damage real data. Record the identity used and the denial returned by the provider.
Finally, make the staging release fail in a safe way. Confirm that the agent can inspect the failure with the same access. A workflow that requires administrator permissions every time a build fails is not ready for routine use.
Repeat these checks when you change the role, way credentials are supplied, or deployment tools. Permissions can drift as new services and exceptions are added.
Treat logs as access to data
Reading logs may sound harmless, but a log can contain email addresses, tokens, or customer data. Before sharing it with an agent, decide what the task needs and what the log should never contain.
For a failed API release, startup output and an error message may be enough. For a failed customer request, a request ID can connect the right records without exposing the full payload. Remove secrets at the point where logs are written, rather than relying on someone to redact every incident afterward.
Also decide where the agent's output is kept and who can read it. A useful record of the work should not become a second, uncontrolled copy of customer data.
How Forte changes the task
When you connect a Forte Service to a repository and branch, a push can start the build and deployment. The agent can inspect the result and logs together in the release view, so your team can use that workflow without assembling it from separate cloud services. Forte deployment guide
Forte has organization roles and custom permissions for actions on resource types. Check the permissions of the member or integration you use. An owner has full access, and a broad organization role should not be treated as proof that production is out of reach. Organization permissions
Run the same rehearsal on Forte. Follow the selected commit into its deployment, test an allowed task, and confirm the chosen credential's limits. The platform's release process does not decide who may approve your schema changes or which customer data the agent may inspect.
The next useful step is a short policy for one app. State what the agent may read, what it may change, and which actions need a person. Then test that policy against a staging Service. Trust grows from a workflow you can inspect and limits you can verify.