How to structure an AI SaaS with security on Azion

An AI SaaS can bring together a serverless API, a database, a language model, and protection tools. When these components are spread across different vendors, the team has to manage configurations and investigate events in more than one environment.

At the same time, coding agents such as Claude Code and Codex can speed up the creation of applications and APIs. To keep up with that pace, teams need to build the review and configuration of security controls into the development workflow.

On the Azion Platform, application, data, AI inference, and security controls can come together in one place, and the policy can be declared as code, reviewed, and versioned alongside the application.

In this article, we use a fictional financial SaaS to show how these components fit together and how security becomes part of the development and deploy workflow.

The architecture of the example SaaS

The example is a fictional financial management app for small businesses that records transactions, imports bank statements, and has an AI assistant that answers questions about cash flow. Payments arrive through a webhook from an external gateway.

The table below compares an architecture spread across vendors with what Azion offers for each piece:

The API runs on Functions and reads transactions from SQL Database. The assistant calls an AI Inference model from the function itself, with no key from another provider, and receives only the aggregated totals, never the full table.

Security in the development and deploy workflow

The security policy can be managed in more than one way. With the Azion CLI, it is declared in azion.config.ts, next to the application code, and teams that use Terraform declare the same resources with the Azion provider. Since in both cases the policy lives in versioned files, changes go through the same code review process. The API, on the other hand, lets you automate changes from other tools.

In this workflow, it’s worth separating two roles: the coding agent, such as Claude Code or Codex, helps the team develop and configure the SaaS, while the AI assistant is part of the product and calls a model to answer users’ questions.

Azion’s MCP Servers give coding agents access to documentation, code samples, and CLI and API references. Depending on the permissions granted, they can also create or change account resources, so it’s up to the team to decide whether the agent prepares changes for review or applies them directly.

With the configuration in the repository, the workflow can follow four steps:

1. The team, with or without a coding agent, prepares code and policy changes in the repository.
2. The security team reviews and approves the changes in code review.
3. The Azion CLI creates or updates on the platform the policy declared in the file.
4. Real-Time Events lets you query, per request, how the Firewall controls acted.

APIs and AI endpoints under the same policy

The app has distinct routes, such as login, statement import, the AI assistant, and the payment webhook, and each one can have its own rules in the same Firewall. The assistant is protected like any other API because it also receives HTTP requests, and the same applies to agents in production.

The table below shows the risk and protection for each route:

The network layer doesn’t solve everything: authorization across customer companies, webhook signature verification, validation of uploaded files, and protection against prompt injection remain the application’s responsibility.

Policy as code, reviewed in code review

The problem starts at the first deploy: without rules, login accepts unlimited attempts and the webhook accepts calls from any origin.

The snippet below illustrates how a team could declare a rate limit rule in azion.config.ts. Parameters should be adjusted to the application’s traffic and needs, and the full file reference is in the Azion CLI documentation.

firewall: [
  {
    name: 'finance',
    active: true,
    waf: true,
    rules: [
      {
        name: 'login-rate-limit',
        active: true,
        criteria: [
          { variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/api/auth/login' },
        ],
        behaviors: [
          { type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '5' } },
        ],
      },
    ],
  },
],

With this rate limit rule, login accepts one attempt per second per IP in each data center, with a burst of 5: the excess is queued, and anything beyond the burst receives a 429 status. These values are only an example and should be calibrated with real traffic, since someone who mistypes a password usually tries only a few times, while an automated attack tries many more.

The webhook, on the other hand, uses another rule, in which a Network List holds the payment gateway’s IP ranges and the Firewall denies anything from outside it.

Because the policy is versioned, every change goes through code review before it’s applied. The Firewall can also be reused: instead of copying rules, a new workload’s deployment can reference an existing Firewall by name or ID. Likewise, a change to a Network List reaches every rule that references it, without editing each rule.

WAF, Bot Manager, and DDoS Protection in one control plane

On Azion, WAF, Bot Manager, DDoS Protection, and Network Shield operate under the same policy and the same observability, avoiding duplicated rules across tools from different vendors. The WAF Rule Set is applied by a rule in the same Firewall and starts in learning mode, in which it only identifies and logs suspicious requests without interrupting traffic.

The move to blocking mode, in which those requests are refused, depends on analyzing real traffic and false positives. As a reference, the documentation suggests switching after 3 days in which no legitimate request would have been blocked. Because the policy is in the repository, this change is made in the configuration file and goes through the same code review as the other rules before it’s applied.

Inspection and blocking happen in the data center that receives the request, without waiting for prefix re-announcements on third-party networks, and a request blocked by a Firewall rule never reaches the origin. DDoS Protection is always on, with no configuration. Bot Manager, in turn, scores each request by signatures, fingerprint, reputation, and behavior, and acts on those above the threshold the team sets, before they reach the application.

Per-request visibility for investigation and auditing

Real-Time Events gives you access to the requests that pass through the Firewall, with the WAF fields, available for querying within 30 seconds and retained for 7 days by default.

To investigate a block, each event includes fields such as wafMatch, which lists the violation and the part of the request that triggered it, and wafScore, which shows the score by threat family. If Debug Rules is enabled on the Application or the Firewall (it’s off by default), the stacktrace field also shows which rules ran.

Data Stream exports these events to external systems, feeding SIEMs, data lakes, and analytics tools. Destinations include Splunk, Datadog, QRadar, Elasticsearch, Kafka, S3, BigQuery, and Azure Monitor. In audits such as PCI DSS or LGPD, these records help build evidence of how the controls acted, without combining logs from multiple vendors, but they don’t demonstrate compliance on their own.

Companies that trust Azion to protect their applications

Companies that can’t afford to stop already trust Azion to keep applications and APIs online during attacks. In the financial sector, Crefisa relies on Azion’s Firewall to protect applications and APIs: it mitigated millions of complex attacks, including DDoS, malicious bots, and web threats, and migrated dozens of domains to Azion during the transition from a traditional data center to the cloud. Read the Crefisa case study.

For others, AI and security are part of the same business. Axur, a digital security company, moved its model inference to AI Inference and reached 5 minutes between detecting a threat and requesting its takedown, with more than 30,000 automated takedowns per month. Read the Axur case study.

Security at the pace of development

With application, data, AI inference, and security on the same platform, the team reduces integration across vendors and brings the security policy into the same workflow as the code. Coding agents can help prepare the rules, and the team reviews, versions, and reuses the policy for the next applications, APIs, and agents in production.

Start free or talk to a specialist.

Next steps:

• Azion MCP Servers documentation
• azion.config.ts reference

Frequently asked questions

Can the coding agent apply a security policy without human review? That depends on the permissions granted to the agent and the workflow defined by the organization. Through Azion’s MCP Servers, the agent queries the documentation and can create resources such as Firewall rules and Network Lists. That’s why the security team should approve changes in code review before deploy.

How do you protect an AI endpoint against abuse? With a combination of Firewall controls: rate limit per IP, Bot Manager, WAF, and rules that reduce request volume, such as geoblocking. In the code, limits on question length and response tokens complete the protection and help control inference cost.

Does the Azion WAF block attacks from day one? Yes, in most cases, because the WAF detects attack signals even when they don’t match a complete known signature. Even so, the recommendation is to start in learning mode and switch to blocking mode after analyzing real traffic and handling false positives.

Does the WAF protect against prompt injection? The WAF filters web attacks such as SQL injection and XSS, but prompt injection lives in the content of the messages sent to the model. With Functions, the team can implement inspection of the JSON content of requests and create its own business rules as code. In the application, limiting the data and tools the model can access, validating actions, and reviewing responses remain necessary.

Does Azion protect both serverless and traditional applications, hosted in the cloud or on-premise? Yes. Serverless applications run on Functions, and traditional applications, hosted in another cloud or on-premise, sit behind the Azion proxy. In both cases, the same Firewall and the same WAF Rule Set inspect requests before they reach the application.

What is security as code on Azion? It means declaring the security policy, with Firewall, WAF Rule Set, Network Lists, and rate limit, in versioned files in the application repository: azion.config.ts, used by the Azion CLI, or the resources of the Azion Terraform provider. Changes go through code review and are applied by the chosen tool. With Functions, you can also write code that handles each request according to the application’s needs.