The AI Gateway: Prompt Firewalls, Token Limits, and the Four Access Planes Every AI System Needs

If you list every control CompTIA names in SecAI+ objectives 2.2 and 2.3, something jumps out: almost all of them sit in the same place. Prompt firewalls, templates, rate limits, token limits, input quotas, modality limits, endpoint access controls. They are not scattered across the architecture. They are the job description of one component, the AI gateway, and once you see the architecture that way the "given a set of requirements, implement controls" questions become a matching exercise.

Why the gateway is the control point

A model has no security of its own. It cannot tell a customer from an attacker, a permitted question from a forbidden one, or a reasonable request from one designed to run up a bill. Everything the model does not know has to be decided before the request reaches it, and enforced on whatever comes back. That is the gateway: a chokepoint between callers and models, where identity is established, policy is applied, limits are enforced, and every interaction is logged.

The architectural rule that follows is simple and heavily tested: there must be no path to the model that does not pass the gateway. A developer's direct API key, a legacy integration that calls the provider straight, or an agent with its own credentials all defeat every control in the diagram at once.

Model controls versus gateway controls

The objective splits controls into two families, and the exam expects you to place each one correctly.

The pattern to internalize: model controls shape behavior, gateway controls enforce policy. A model guardrail is a request; a gateway rule is a decision. When a question asks for a control that cannot be talked around by a clever prompt, the answer is at the gateway.

Prompt templates deserve a specific mention, because they are the cheapest control in the list and the one most teams skip. If the application assembles a prompt by gluing the user's text onto the end of the system instructions, the user is editing the instructions. A template puts user input in a marked slot, escapes it, and keeps the instructions out of reach. It does not stop prompt injection arriving through retrieved documents, but it closes the most direct path.

Limits are controls, not configuration

Candidates tend to read rate limits as a performance setting. The objective lists five distinct limits and treats every one as a security control, because each one bounds a specific attack.

• Rate limits cap requests per caller per window. They slow model extraction and stop a runaway integration from becoming a denial of service.
• Token limits cap the size of the prompt and the response. A prompt limit blocks the "paste a 200-page document with instructions buried on page 140" attack; a response limit stops a single request generating a bill.
• Input quotas cap total consumption per caller over a longer period, which is what catches slow, patient extraction that never trips a per-minute rate limit.
• Data size and quantity limits apply to uploads and batch jobs: how large a file, how many files, how many rows. They protect the pipeline behind the model, not just the model.
• Modality limits restrict which input types a caller may send. A text assistant that also quietly accepts images has doubled its attack surface, because instructions can be hidden in an image the text firewall never reads.

Two of those limits interact in a way the exam likes to probe. A rate limit and an input quota measure the same caller over different windows, and an attacker who knows only one exists will simply pace themselves under it. A per-minute limit of sixty requests allows 86,400 requests a day, which is more than enough to extract a classifier's decision boundary in a week. The quota is the control that closes that gap, which is why the objective lists both rather than treating one as a variant of the other.

Placement matters too. The limits belong at the gateway rather than in each application for the same reason firewall rules belong on the firewall: an application-level limit can be forgotten in the next integration, and it cannot see the caller's total consumption across every application that uses the same model. A gateway that fronts several models can also route by policy, sending regulated data only to the private tenant and sensitive workloads only to versions that passed evaluation, which is the enforcement mechanism behind the sanctioned-versus-unsanctioned distinction that Domain 4 governs.

The four access planes

Objective 2.3 asks you to implement access controls for AI systems and names four targets. Treat them as four separate planes, each with its own principal, its own policy, and its own failure mode.

Data access is the plane that catches people, because it is the one where the model's identity and the user's identity diverge. A retrieval system that queries the document store with a service account sees everything the service account can see, and will happily summarize the CEO's compensation for an intern who asked nicely. The correct design filters retrieval by the requester's own permissions, before the documents ever reach the prompt. This is the same problem securing a RAG system is mostly about.

Agent access is the plane that is new. An agent that can call tools has authority, and the question is whose. The answer the exam rewards is least privilege per tool, with the ability to cause side effects (send, spend, delete, deploy) gated behind explicit approval. Excessive agency is the failure mode, and it is on the OWASP list for a reason.

A guardrail you have not tested is a hope

The last item in objective 2.2 is guardrail testing and validation, and it is there because guardrails fail silently. A prompt firewall with an outdated rule set blocks nothing and reports nothing. A modality limit that was never exercised may have been quietly removed during a library upgrade.

Testing has two halves. Positive testing confirms the guardrail fires on what it should catch: a maintained set of known injections, jailbreaks and sensitive-data probes, run after every change. Negative testing confirms it does not fire on what it should allow, because a guardrail that blocks legitimate use gets disabled by the first product manager who notices. Both belong in the deployment pipeline, and both produce the evidence an auditor will ask for.

The broader point is the one that runs through the whole of Domain 2: controls are claims until they are tested, and red teaming is how the claim gets checked against an adversary rather than a checklist.

Gateway and access controls are objectives 2.2 and 2.3 of Securing AI Systems, the 40% domain, and they are the enforcement side of the monitoring and auditing that objective 2.5 asks you to build on the same logs. Work all 36 topics with our SecAI+ Domain 2 study guide.

#SecAIplus #AISecurity #AIGateway #PromptFirewall #RateLimiting #AccessControl #LLMSecurity #ZeroTrust #CompTIA #CyberSecurity