Give the AI step its own restricted key with only the permissions the task needs, require a human to approve high-risk actions such as refunds and payouts, and log every call. Never reuse a general secret key, because the step may act on text an attacker wrote.
Why this is different from a normal integration
A conventional automation follows fixed steps. An AI step chooses actions based on text it reads, such as a customer email. If that text contains instructions, the step may follow them. So the permission set must assume the step can be misled, and the key must be small enough that a mistake is survivable.
Stripe's documentation has a concrete example of this design. When you create a restricted API key, you can tag it as belonging to an autonomous agent. Agent-tagged keys work like other restricted keys for authentication and permissions, but they are automatically subject to approval rules, which require a designated reviewer to approve sensitive actions before they take effect. Default rules cover high-risk actions such as payouts, refunds and account configuration changes. Stripe describes this as a safeguard against agent mistakes and unexpected behavior.
You may not use that provider. The pattern still applies.
Controls and what each stops
| Control | Stops |
|---|---|
| Dedicated restricted key for the AI step | A mistake spreading to unrelated operations |
| Read only by default | Accidental writes |
| Human approval for refunds, payouts and settings | Large, irreversible actions from bad instructions |
| Amount and count limits | Many small harmful actions |
| Network restrictions on the key | Use of the key from elsewhere if it leaks |
| Full request logging | Blind spots during review |
| Separate sandbox for testing | Experiments touching real money |
Steps
- Write down what the step must do in one sentence. If it needs three kinds of access, split it into three steps.
- Create a restricted key for just that. Name it after the step and its owner.
- Test in a sandbox with adversarial inputs, such as an email that says "refund the last ten orders".
- Put an approval gate on actions that move money or change settings. The reviewer sees the proposed action and the source text.
- Add limits: maximum refund, maximum actions per hour, allowed customers.
- Log inputs, proposed actions, approvals and results, in a place the AI step cannot edit.
- Review the logs weekly for the first month, then monthly.
- Plan a kill switch: one place to disable the key.
What not to do
- Do not let the step read untrusted text and also hold broad write access.
- Do not make the approval a rubber stamp. If reviewers click through, shorten the queue or tighten the limits.
- Do not store the key in the prompt or in the flow notes.
For the broader agent identity question, see how to offboard an AI agent identity and its credentials.
Quick check
Is a read only key enough?
It helps a lot, since reading is lower risk than writing. But reading can still expose customer data, so scope it to the objects the task needs.
Does approval make the AI step pointless?
No. Approval applies only to risky actions. Routine, low-risk actions can still run on their own within limits.
Safeguard's agent identity, MCP Guardrail and policies are GA capabilities for scoping what agents can do. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
