Often you can test your own API in the cloud without asking first, but the provider's policy decides, and some activities are banned either way. Flooding, denial of service and testing the provider's own services are the usual limits. Read the current policy before every new engagement and keep a written scope.
What the policies say
Policies change, so treat the summary below as a snapshot from 19 October 2026 and re-read the pages yourself.
| Topic | One provider's published position | Another provider's published position |
|---|---|---|
| Prior approval for your own resources | Not needed for a listed set of services, including its API gateway, serverless and load balancer products | Testing is limited to your own tenant or assets you have explicit authorization to test |
| Denial of service and flooding | Prohibited, including request flooding and login or API request flooding | Prohibited, including flood attacks and network-intensive fuzzing that generates excessive traffic |
| Testing the provider's own infrastructure | Not permitted | Accessing data or tenants you do not own is prohibited |
| Using a found issue further | Report issues caused by the provider's own tools or services | Do not go beyond the first proof of concept, report it instead |
Two details matter for API work. The first provider lists some services as prohibited for outbound penetration testing, so check the exact service name rather than assuming a whole category is fine. The second provider names "network-intensive fuzzing or automated testing that generates excessive traffic" as off limits. A scanner that hammers an endpoint can cross that line without anyone intending it.
Why this affects an API scan in particular
API scanners send many requests with changed parameters. That is their job. It also means a badly tuned run looks a lot like request flooding from the outside. Both policies treat that as a violation, and one of them states that you are responsible for damage your testing causes.
Rate limits you rely on in production may also fire during a test. That is useful information, but it can lock out your own test account at the worst moment.
A short pre-scan routine
- Name the exact hosts, paths and API versions in scope, in writing.
- Check the provider policy for each service those hosts run on. Note the date you checked.
- Set a request rate ceiling in the scanner and agree it with whoever runs the platform.
- Choose a window and tell the on-call engineer. A scan that trips an alert should not start an incident.
- Use test accounts you created. Never use credentials that are not yours.
- Keep a stop condition: who pauses the scan, and how.
If the API sits behind a gateway you do not operate, such as a partner's or a vendor's, you need that owner's permission, not just your cloud provider's. Written consent from the owner of the system is the baseline in the second policy above.
What to keep as a record
A one-page rules of engagement note is enough: scope, dates, rate ceiling, contacts, test accounts, and the policy pages you checked. It also helps later if a customer asks how you test, or an auditor asks for evidence that testing is planned.
Where Safeguard fits
Knowing what you have to test is half the job. Safeguard's asset discovery and compliance evidence automation can help you keep an inventory and a dated record of what was reviewed. This post is not legal advice, and the cloud policies above are the provider's, not ours.
Worked example: planning a first scan of a staging API
A small team runs a payments API on a major cloud. The API sits behind the provider's managed gateway, with serverless functions behind it. The team wants to run an authenticated scan against staging before a customer review. Here is how they would work through the permission question, step by step.
Step 1: list the services involved. The team writes down every service that handles a request: the gateway, the functions, a managed database, and a queue. The policy pages from the providers talk about services by name, so the list has to be at that level of detail, not "our cloud setup".
Step 2: check each service against the policy. For one provider, the published page lists services where testing your own resources needs no prior approval, and says some services are prohibited for outbound penetration testing. The team notes which of their services appear in the permitted list and which do not. Any service that is not on the list becomes a question for the provider's support channel, not an assumption.
Step 3: check the activity, not just the target. Even where no approval is needed, the policies ban flooding and denial of service. The team's scan config has a request rate setting, so they set a ceiling well below anything that would look like a flood, and write that number into the plan.
Step 4: confirm who else owns pieces of the path. Staging calls a partner's sandbox API for card tokenization. The team does not own that host. Scanning the partner's endpoint would need the partner's written consent, so the team excludes it and stubs the partner call during the scan.
Step 5: write the one-page note.
| Field | Example entry |
|---|---|
| Targets | Staging API hostname, versions v1 and v2 |
| Excluded | Partner sandbox host, the managed database, anything outside the staging account |
| Provider policy checked | Date, and the two policy pages |
| Rate ceiling | A fixed requests per second figure, agreed with the platform owner |
| Window | Tuesday, off-peak, with the on-call engineer informed |
| Accounts | Two test users, one admin, one read-only role, all created for this test |
| Stop rule | Platform owner or security lead can halt the scan at any time |
| Retest | Date set for confirming fixes |
Step 6: file it. The note goes in the shared evidence folder next to the scan output. Six months later, when a customer asks how testing is governed, the team can answer from a document and not from memory.
The whole exercise takes under an hour. Skipping it can take much longer to repair, because a scan that trips a provider's abuse systems or a partner's alarms becomes an incident review.
What to do when the answer is unclear
If a policy page is silent about your service, or two pages seem to conflict, ask the provider in writing and wait for the reply. Keep the reply with the scan record. Do not treat silence as approval, and do not scan the unclear part in the meantime. Test the rest, and add the unclear service to a follow-up list.
Try it yourself
Open the demo and look at the list of requests an example scan sends. Count how many a real run would multiply, and compare that with the rate ceiling in your own plan.
Click through it at your own pace, or open it full screen.
Quick check
Can I run a heavy load test as part of an API security test?
Be careful. Both policies above prohibit denial of service and flooding. Volumetric or simulated attack testing usually has its own separate process, so check it before you plan one.
Does a staging copy of my API need the same approval?
If it runs on the same provider, the same policy applies. Confirm the services it uses are covered, and keep the scope note.
Does a bug bounty program replace a rules of engagement note?
No. A bounty program publishes terms for outside researchers. Your own scheduled testing still needs scope, a rate ceiling, a window and a stop rule, and a record of the provider policies you checked.
Sources
Last reviewed: 19 October 2026.
