No security team: how to use an AI agent without losing control

A SaaS without a security team can hand its routine security work to an AI agent without losing control of it. The Azion Platform blocks attacks in real time, and a scheduled coding agent, such as Claude Code, reads traffic events and blocks abusive IPs with an expiration date. You decide how far the agent goes, since Azion limits its access through its token and you set in the instructions file how long each block lasts and what needs your approval.

On a lean team, security usually loses to the next feature. Nobody has a free afternoon to go through WAF logs, and attacks tend to show up right in launch week. In practice, protection stays at the default, and someone only looks at the events after a customer complains.

Handing everything to an agent with no limits trades one problem for another. An agent with broad access to the account can make mistakes at scale, and you only find out later. That’s why the approach that works is to split the job, leaving the routine to the agent while you set the rules and approve anything that changes the policy.

Does using an AI agent for security mean losing control?

No, as long as the agent’s access is limited in the platform, and not only by its instructions. On Azion, the agent acts with the token you created, which only gives access to the resources you allowed, such as Network Lists. The list it writes to, each block’s expiration date, and what needs your approval are set in its instructions and in the tools you allow it to use, and every blocked request is logged in Real-Time Events.

Each part of the system has a different role:

The agent also isn’t in the request path, so if it fails or runs late, traffic keeps going through the Azion Firewall with the same rules as before. If it misreads an event, it can block a legitimate IP, but it doesn’t change Firewall or WAF rules, and the FAQ shows how to undo the block.

What does Azion block on its own, without an agent?

The first layer doesn’t depend on AI, because DDoS Protection, WAF, rate limiting, and Bot Manager decide each request in the data center that receives it, and blocking doesn’t wait for anyone to wake up.

This post starts from an app that is already behind Azion with these protections on. If yours isn’t yet, the path is in the post How to protect a SaaS that’s under attack, without migrating or rewriting anything.

What controls does Azion give you over the AI agent?

These controls define and record what the agent does:

• The agent connects to the Azion MCP servers with a personal token, and the token decides what the write tools can change. The MCP servers documentation says to scope the token to the resources the agent needs. On Azion, each user’s access to the account is defined in Teams Permissions. Create a user just for the agent in Users Management and add it to a team with only View Real-Time Events, to read the events, and View Network Lists and Edit Network Lists, to read and write Network Lists. The agent’s token is generated with that user, so the agent doesn’t use the token of whoever administers the account.
• A personal token has an expiration date, from 1 day to 1 year or a date you choose, and it can’t be changed after it’s created. Prefer a short expiration, renew the token before it expires, and set up an alert for when the job fails. To revoke the agent’s access, just delete the token.
• Each IP goes into the list with an expiration date, and on every run the agent rewrites the list, which drops the expired items. That cycle is what ends a wrong block, as explained below.
• Every MCP server tool that creates, changes, or deletes accepts dry_run, which returns the exact API request without sending it. In the first few weeks, the agent only shows what it would do, and you check it.
• Every blocked request shows up in Real-Time Events with the IP, the route, and status 403. Together with the job log, that shows why the IP went into the list and what happened to its requests.

The controls work in two layers. On Azion, the agent’s team defines which kind of resource it can access, and the Edit Network Lists permission applies to every list in the account. In the agent itself, the instructions file defines which list it writes to and when it uses dry_run, and a fixed set of allowed tools defines what it can call, namely create_graphql_query from observe, get_network_list and update_network_list from secure, and the ones that send the summary. In Claude Code’s non-interactive mode (claude -p), a tool that needs approval only runs if it’s allowed, for example in --allowedTools; the others are denied. The GitHub action runs Claude Code in this same mode.

How does the AI agent monitor SaaS traffic?

The agent reads your account’s Real-Time Events on every run. It runs in non-interactive mode in a scheduled job, for example in GitHub Actions, and follows an instructions file versioned in the repository.

Two MCP servers do the work. In observe, the create_graphql_query tool writes a GraphQL query from a plain-language goal and runs it on your account, with the real-time-events data source. In secure, the update_network_list tool writes the items of the block list.

The data comes from the workloadEvents dataset, the same one behind Real-Time Events. Each request becomes queryable 20 to 40 seconds after it happens and is kept for 7 days. These are the fields the agent cares about most:

• remoteAddress: the IP that made the request.
• requestUri and host: the route and domain under attack.
• status: the HTTP status code, where 429 means rate limiting and 403 means a Deny rule.
• wafBlock, wafMatch, and wafAttackFamily: whether the WAF blocked the request, the violations it found, and the attack family, such as SQL injection or XSS.

With that, the agent answers the questions you’d ask if you had the time, such as which IPs got the most 429s on login, which routes concentrate WAF blocks, and whether any IP shows up in both results.

How does the agent block IPs without touching the security policy?

By writing to a Network List, without touching the Firewall rules. A Network List is a list of IPs, ASNs, or countries that Firewall rules check against, with up to 20,000 items. The rule that blocks whoever is on the list is yours. You create it once in the Firewall, in Console, and the agent’s token has no permission to change it. The agent only changes the contents of the list, which it writes directly through the API, with the secure MCP server.

The rule lives in the Firewall Rules Engine, with the Network matches criterion and the block Network List chosen by name, and with the Deny (403 Forbidden) behavior. For the Firewall to use Network Lists, the Network Shield module must be on. IP/CIDR lists accept IPv4 and IPv6 addresses, and the other criteria and behaviors are in the Firewall Rules Engine documentation.

In IP/CIDR Network Lists, the expiration date is written after the address, with the --LT prefix and a UTC time:

203.0.113.45 --LT2026-10-29T18:00:00Z
198.51.100.0/24 --LT2026-10-30T06:00:00Z

On Azion, expired items leave the list the next time it’s saved, as the Network Lists documentation explains, so the agent writes the whole list on every run, even when there’s no new IP.

Changing the list takes effect as soon as it’s saved, and a change to the items of a list that rules already use reaches traffic within seconds. From then on, requests from that IP get a 403 and show up in Real-Time Events with that status; with Debug Rules on, the stacktrace field also shows the rule that blocked them, as the post on protecting a SaaS without migrating explains.

When does the agent act on its own, and when does it ask for approval?

The agent acts on its own on reactions and asks for approval on policy. Blocking an IP for a limited time is a reaction, so it does it and lets you know. Changing the rate limit, turning on the WAF’s blocking mode, or creating a new rule is policy, so it proposes the change in the summary, and you decide whether to apply it in Console.

An instructions file like this one draws that line:

# SaaS security routine (runs every 15 minutes)

1. Query workloadEvents since the previous run for app.yoursaas.com.
2. Block, in the "agent-temporary-block" Network List, for 6 hours,
   IPs with more than 200 responses with status 429 on /login or more than 20 WAF blocks.
3. Never block IPs on the "known-customers" list or ranges larger than /24.
4. Rewrite the whole list on every run, even with no new IP, keeping the fixed item created with the list.
5. Post a summary in the #security channel: blocked IPs, reason, and route.
6. If the same pattern shows up in 3 runs in a row, propose a permanent rule
   in the summary. Don't apply it.
7. Don't change the Firewall, WAF, or rules through the API. Only the Network List.

The numbers in the file are examples, to be tuned to your app’s real traffic. With the summary, you follow what the agent did without opening Console. Instead of finding out about the attack from a customer, you read in Slack that 14 IPs were blocked on login at 3 a.m. and decide, over coffee, whether to approve the permanent rule the agent suggested.

Step by step to use an AI agent for SaaS security without losing control

1. Put the app behind Azion, with WAF, rate limiting, and Bot Manager, as shown in the post on protecting a SaaS without migrating.
2. In Console, under Network Lists, create an IP/CIDR list named agent-temporary-block, with 192.0.2.1 in the List field. This address is reserved for documentation and stays on the list as a fixed item, with no expiration date, because a Network List needs at least one item. Optionally, also create a known-customers list with your customers’ IPs, which the agent checks before blocking.
3. In the app’s Firewall, check on the Main Settings tab that Network Shield is on. On the Rules Engine tab, create a rule with the Network matches agent-temporary-block criterion and the Deny (403 Forbidden) behavior.
4. To see the rule that blocked a request in the stacktrace field, turn on the Debug Rules option on the Main Settings tab of the same Firewall.
5. In the account menu, under Teams Permissions, create a team with View Real-Time Events, View Network Lists, and Edit Network Lists. Under Users Management, create a user just for the agent with an email address you control, pick that team in the Teams field, and activate the account from the invitation email.
6. Sign in to Console as the agent’s user and, under Personal Tokens in the account menu, generate the personal token with a short expiration. Write down the expiration date so you can renew the token before that date.
7. Create a GitHub repository for the agent and add the instructions file to it, with the block rules (how many 429 responses or WAF blocks put an IP on the list), how long each block lasts, the exceptions, the summary channel, and the order to use dry_run for the first few weeks.
8. Prepare the repository for the agent.
   • Install the Claude GitHub App and give the workflow the id-token: write permission, which the action uses to authenticate.
   • To send the summary, choose a tool for the channel, such as a Slack MCP server.
   • Store the Azion token, the Claude API key, and the summary channel’s token as repository secrets.
9. Schedule the agent in GitHub Actions with a workflow that uses the anthropics/claude-code-action action.
   • Use the schedule trigger and a prompt that tells it to follow the instructions file.
   • In claude_args, pass an --mcp-config with the observe (https://observe-mcp.azion.com/mcp) and secure (https://secure-mcp.azion.com/mcp) MCP servers, authenticated with the Authorization: Token header and the agent’s token, and with the MCP server for the summary channel.
   • In the same claude_args, pass an --allowedTools with the exact name of each allowed tool, in the mcp__<server>__<tool> format, using the server names from --mcp-config. For example, mcp__azion-observe__create_graphql_query, mcp__azion-secure__get_network_list, and mcp__azion-secure__update_network_list, plus the tools the agent uses for the summary.
   • Set up an alert for when the workflow fails.
10. Follow the summaries and tune the block rules in the instructions file. When the results look right, remove the order to use dry_run from the file, and the agent starts writing to the block Network List.

Automated control so you can focus on what matters

Without a security team, the person who usually finds out about an attack is the developer, from a customer complaint or a spike on the dashboard. With the agent, the routine work leaves your hands, but the control stays with you. The token’s permissions and the Firewall rules keep applying on every run, because Azion is the one enforcing them.

Only what needs a decision reaches you, such as a pattern that repeated and turned into a proposed permanent rule, and the rest of your time goes to the product.

Need help with your SaaS security? Talk to an Azion expert or create a free account to test the flow with your app.

Frequently asked questions

How do you handle SaaS security without a security team? Leave real-time mitigation to the platform, with DDoS Protection, WAF, rate limiting, and Bot Manager, and hand the routine work to a scheduled AI agent that reads events, blocks abusive IPs for a limited time, and reports. You set the agent’s permissions and block rules and approve changes to the policy.

Is it safe to use an AI agent for my SaaS security? It can be, when the agent’s access is limited in the platform and what it does is defined in its instructions. On Azion, it acts only with the token’s permissions, which limit it to Network Lists, and its instructions define which list it writes to and how long each block lasts. Every blocked request is logged in Real-Time Events. Changes to Firewall and WAF rules stay with you, and you apply in Console what the agent proposes.

How do you limit an AI agent’s permissions on Azion? Scope the token the agent uses. Create a user just for the agent in Users Management, add it to a Teams Permissions team with the minimum it needs, such as View Real-Time Events, View Network Lists, and Edit Network Lists, and use it to generate a personal token with a short expiration. This way, the agent doesn’t use the token of whoever administers the account, and to revoke its access you just delete that token.

What happens if the agent’s job stops running? Traffic stays protected, because the agent isn’t in the request path, and the Firewall keeps applying the same rules. The blocks already on the list stay in place, so renew the token before it expires and set up an alert for job failures. To unblock an IP right away, open the Network List in Console, delete that IP’s line in the List field, and save.

How do you block IPs automatically on Azion? With an IP/CIDR Network List referenced by a Deny rule in the Firewall. The agent writes the IPs to the list through the secure MCP server, each with an expiration date (--LT), and rewrites the list on every run to drop the expired ones. The change takes effect as soon as the list is saved.

What if the agent blocks a real customer? The block ends on the agent’s first run after the expiration date. To unblock right away, delete the IP’s line in the Network List, in Console, and add the IP to the known-customers list so the agent doesn’t block it again. An exceptions list with known customer IPs, which the agent checks before blocking, lowers that risk.

Which AI agent can I use? The Azion MCP servers work with clients such as Claude Code, Cursor, Codex, and Gemini CLI. To run on a schedule, the client needs a non-interactive mode, such as Claude Code’s claude -p.

How long does it take from the attack to the agent’s block? It’s the sum of 20 to 40 seconds for the event to show up in Real-Time Events, the interval until the agent’s next run, and a few seconds for the Network List change to reach traffic. Meanwhile, rate limiting, WAF, and DDoS Protection keep acting on the request itself.