Shadow AI exposure
IBM's 2026 report found that 68% of breached organizations lacked AI governance policies to manage AI or detect shadow AI, and that security incidents involving shadow AI rose from 20% to 43%.
What an AI guardrails platform does, which guardrails you need, where to enforce them, and how to compare guardrail approaches before you choose a platform.
Updated October 2026 · By the Folio3 AI Editorial Team · Reviewed by Abdul Sami, Head of AI Development
An AI guardrails platform checks every AI input and output against policy before it reaches a model or a person, then blocks, masks, or reroutes whatever breaks the rules.
AI Guardian applies identity, PII masking, policy, model routing, spend caps, and audit trails to every AI request, so teams can use approved AI in Teams, Slack, and web with less shadow AI exposure.
Definition: An AI guardrails platform is software that enforces policy on AI traffic at runtime. It inspects prompts, files, and responses as they move, applies rules for data, security, topic, access, and cost, and records what it decided.
A platform differs from a single guardrail because it manages many guardrails across users, models, and agents from one place. The term overlaps with three neighbors, and the differences decide what you buy.
| Term | What it does | Where it stops |
|---|---|---|
| AI guardrails | Enforce rules on each request and response at runtime | Needs policy decisions from elsewhere |
| AI governance | Decides policy, ownership, and oversight | Governance platforms may focus primarily on policy, inventory, and oversight rather than inline enforcement |
| AI gateway | Routes traffic to models, and many now add guardrails, identity, budgets, and agent controls | Often built for developer traffic, so employee workspaces and executive reporting vary by product |
| Content filters | Block listed words or harm categories | Do not understand roles, files, or business context |
Governance writes the rules, a gateway moves the traffic, and guardrails enforce the rules on that traffic. A platform that combines all three reduces the gaps between them.
Seven types cover most enterprise risk. Not every product needs to own every layer, and products rarely cover all seven, so use the table to mark which gaps you would fill another way.
| Type | What it checks | Example control |
|---|---|---|
| Input guardrails | Prompts and retrieved content | Prompt injection and jailbreak detection |
| Data guardrails | Text and attached files | PII, secret, and document redaction |
| Output guardrails | Model responses | Toxicity, leaked secrets, and grounding checks |
| Topical guardrails | Subject of the request | Off-domain request blocking |
| Access guardrails | Who may use which model | SSO, role-based access, model permissions |
| Cost guardrails | Usage and spend | Token quotas and department caps |
| Agent guardrails | Tools and actions | Tool allowlists and approval gates |
AI Guardian's controls center on identity, inspection of prompts and files, policy, routing, and audit. The comparison below shows how each approach to guardrails covers these types.
IBM and Cyberhaven both describe risk that comes from how people use models, not from model flaws. IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99M and reports a 56% increase in AI-driven attacks. Four exposures show up first.
IBM's 2026 report found that 68% of breached organizations lacked AI governance policies to manage AI or detect shadow AI, and that security incidents involving shadow AI rose from 20% to 43%.
Cyberhaven's 2025 report found that 34.8% of corporate data employees put into AI tools is sensitive, up from 10.7% two years earlier.
OWASP ranks it first in its 2025 Top 10 for LLM applications. A retrieved document can carry a hidden instruction the user never sees.
IBM's 2026 report also found that 92% of organizations with an AI-related breach lacked proper AI access controls. Shared API keys show that a call happened, not who made it.
Most teams discover unapproved AI use only after sensitive files reach a public model. Running a few sample prompts through a governed path shows where employees use AI today and which guardrails close the biggest gaps first.

Guardrails can run in four places, and the place decides what they can see. Most teams end up with more than one layer.
| Layer | Scope | Effort | What it cannot see |
|---|---|---|---|
| SDK or in-app | One application | Per-app integration and upkeep | Other apps, employee tools, personal accounts |
| Cloud provider | One provider's models | Low inside that cloud | Other providers and tools outside the cloud |
| Gateway | Model traffic through one endpoint | Moderate | Employee workspaces and who is using what, unless identity is added |
| Control plane | Users, models, agents, and spend together | One deployment | Application internals, so keep app-level tests |
Per-application guardrails work well for the application you ship. They say nothing about the analyst pasting a contract into a personal chatbot account. Cloud-native guardrails stay inside one cloud and one model family.
An enterprise LLM gateway sees every model call but not the person behind it unless identity is attached. A control plane sits where users, models, agents, and budgets meet, so one policy covers all of them.
AI Guardian is a control plane. It does not replace application-level testing, so teams that ship their own LLM apps usually keep an in-app layer as well.
“A rule written in a policy document does not sit in the request path. A control that runs on every request does, and it only holds if the approved route is also the fastest one.”
Agree on who uses the tool and what must stay protected before you compare features. Then test each criterion against your own files, not a vendor demo set.
-97c75ba1-111c-40c6-80ea-b08b32dab158.png)
| # | Criterion | What to verify | Who asks |
|---|---|---|---|
| 1 | Coverage depth and custom policies | Input, output, data, topic, and agent guardrails; rules you can write yourself | CISO, platform engineering |
| 2 | Document-level PII redaction | Multi-page files and regional identifiers, not only pasted text | CISO, compliance |
| 3 | Employee workspace support | Teams, Slack, web, and mobile, so the governed path is convenient | COO, line-of-business heads |
| 4 | Model-agnostic routing | Commercial and custom models, with fallback | Platform engineering |
| 5 | Role-based cost controls | Quotas and caps by role and department, enforced at request time | CIO, CFO |
| 6 | Agent governance | Internal and third-party agents inherit identity and limits | CISO, platform engineering |
| 7 | Private cloud deployment | Runs in your tenant; what leaves it, and where | CISO, compliance |
| 8 | Audit evidence and export | Identity on every record; export to your SIEM or observability tools | CISO, compliance |
| 9 | Latency and false positives | Measured on your traffic; fail open or fail closed when inspection breaks | Platform engineering |
| 10 | Time to value and total cost | Days to deploy; license, hosting, and engineering time | CIO, CFO |
Four routes exist. Engineering capacity and governance depth decide between them, and cost varies with scope, so the comparison is qualitative.
| Factor | Open-source framework | Cloud-native guardrails | Point security tool | Control plane platform |
|---|---|---|---|---|
| Time to deploy | Fast start, slow operations | Fast inside one cloud | Fast for one use case | Days after alignment |
| Coverage | Flexible, you assemble it | One provider's models | Narrow, such as injection | Users, models, agents |
| Ownership | You run and update it | Provider runs it | Vendor runs it | Vendor builds it, runs in your tenant |
| Cost predictability | Engineers and hosting | Usage-based | License | Setup plus license |
Run these four checks before you sign.
Upload your own multi-page files and ask the vendor to report what it missed.
Show a blocked request in the audit log, with the user named.
Ask whether traffic fails open or closed when inspection stops working.
Measure added latency on your own prompts, and count false positives.
Most guardrail products fall into one of five approaches. Pick the approach first, then shortlist products inside it. Each entry names the job it does best and where it stops, including ours.
| Capability | Control plane (AI Guardian) | Open-source framework | Cloud-native | Point security tool | Gateway |
|---|---|---|---|---|---|
| Employee workspace | Teams, Slack, web, mobile | No | No | No | Varies by product |
| PII handling | Prompts and multi-page files | Via validators or integrations | Text filters, within that cloud | Data leakage defense | Varies, from basic to built-in masking |
| Prompt injection defense | Inspection step | Via validators | Provider filters | Core strength | Built in or via integrated providers |
| Off-domain blocking | Role-based policy | Topical rails you write | Denied topics | Not a focus | Varies by product |
| Role-based routing and spend caps | Yes | No | Limited to that cloud | No | Routing yes; confirm budgets and quotas |
| Agent governance | Governed chains, identity inherited | You build it | Limited | Varies | Varies |
| Private cloud deployment | Your Azure or AWS tenant | Self-hosted | That cloud only | Varies | Self-hosted or SaaS |
| Who runs it | Vendor builds, runs in your tenant | Your engineers | Provider | Vendor | Your engineers or vendor |
Source note: Ratings are Folio3's general assessment of each approach, and individual products vary. Check current vendor documentation before you decide.
Comparison tables only go so far. Watch one employee prompt pass through identity checks, PII masking, model routing, and audit logging before the answer comes back, using your own sample data.
It fits best when staff and agents use AI every day, and security, IT, and finance need one set of rules. It is not the right pick for every team, and the comparison above shows where it is not. Six traits matter for that fit.
-7adc68ba-ba12-4057-9cf9-703a656e9054.png)
It adds identity, routing, budgets, and audit to inspection.
It governs people and agents, not only backend calls.
Staff use approved models in Teams, Slack, web, and mobile, so the governed path is also the convenient one.
Department caps and role-based routing sit in the same policy as data rules.
Multi-agent chains run under the requester's identity, with the same masking and audit as a prompt.
Line-of-business heads set their own quotas and model access without engineering tickets.
SSO matches the user to a role, department, and policy set.
Prompts and documents are scanned for PII, secrets, and injection attempts, then masked or blocked.
Policy checks department quotas, user permissions, and model access, then sends the request to the approved model.
Specialized agents collaborate, retrieve company knowledge, and run approved actions under the same rules.
Token use, cost, policy decisions, and model activity are logged against a named user.
Worked example: Here is one request, with fictional identifiers. A finance analyst uploads a vendor invoice and asks to check the IBAN and Iqama number against the vendor record, then adds a request to plan a weekend trip. Inspection replaces both identifiers with placeholders before the request leaves the tenant. Policy blocks the trip request as off-domain and logs it, and the invoice task continues on the approved mid-tier model.
No guardrail catches every injection attempt, and no platform can guarantee that employees never use unmanaged tools. Keep adversarial testing, output review, and human oversight in your program, and treat model output as untrusted input.
-b6e1249b-2599-4f92-90d5-3fb6b6a30054.png)
Most AI spend comes from routine work sent to expensive models. Guardrails that act on cost turn a risk control into a budget control.
General staff draft and look things up on efficient models, analysts review documents on mid-tier models, and legal and engineering use frontier models for complex reasoning under quotas.
Dollar and token limits give every budget a named owner.
Declining non-business requests keeps organization-funded capacity off personal tasks.
Every record ties tokens and cost to a user, so finance sees who spent what.
Microsoft's own model router documentation describes the same principle: smaller, cheaper models handle simple prompts, and frontier models are reserved for complex tasks.
Modeled scenario: AI Guardian's model shows about 30% lower blended spend in a modeled mixed-workload scenario that rests on stated assumptions. It is a scenario, not a benchmark and not a guarantee. Track cost per completed task rather than cost per token, since a cheaper model can cost more per finished task.
Start with one department, then extend the same controls across the company.
List the AI tools, models, and agents in use, approved or not.
Choose a team with real data and a willing owner.
Agree on what is allowed, restricted, and prohibited.
Run sample requests through every control and check the audit log.
Reuse the same policy set for the next team.
Requirements and alignment sessions record policies, hierarchy, roles, model access, and quotas.
AI Guardian goes live in 4 to 5 business days after alignment, with timing varying by organizational complexity and integrations.
AI Guardian currently starts at $15K for one-time implementation and $8K per quarter for the platform license. Final pricing depends on scope, lines of business, integrations, and deployment requirements. Compare vendors on implementation and recurring license as separate figures, and add hosting and engineering time for open-source options.
| Metric | What it shows |
|---|---|
| Share of AI traffic on the governed path | Whether shadow AI is shrinking |
| Blocked, redacted, and warned requests by policy | Where policy applies pressure |
| Spend per department against cap | Budget ownership |
| Cost per completed task | Quality of model assignment |
| Time to revoke a user's or agent's access | Containment readiness |
Pick one team, set its guardrails and quotas, and see the audit trail within days. The same controls extend to every other department.
| Function | Risk | Guardrail applied |
|---|---|---|
| Finance and banking | IBANs and account data pasted into prompts | Masking before the model call |
| Legal and compliance | Contract text sent to public models | Review inside an approved workspace with redaction |
| IT and security | Scattered personal AI accounts | One governed workspace behind SSO |
| Software and SaaS teams | Source code and secrets in prompts | Secret scanning and role-based model access |
Guardrails supply evidence for these frameworks. They do not make an organization compliant with any of them.
| Framework | What it asks for | AI Guardian control | Evidence produced |
|---|---|---|---|
| EU AI Act, Article 12 | High-risk systems must technically allow automatic recording of events (logs) | Audit | Per-request logs tied to a user |
| ISO/IEC 42001 | An AI management system with policies, roles, and audit | Identity, policy | Role mapping and policy decisions |
| NIST AI RMF | Govern, Map, Measure, Manage | Policy, audit | Policy records and usage reports |
| OWASP Top 10 for LLMs | Defenses for injection and sensitive data disclosure | Inspection | Block and mask events |
| GDPR, Article 5(1)(c) | Personal data limited to what is necessary | Inspection | Masking record per request |
Folio3 is ISO 27001 certified. That certification covers organizational information security management, so prompt-level assurance comes from the controls above.
It is software that enforces policy on AI inputs and outputs at runtime. It inspects each request and response, blocks or masks what breaks the rules, and records the decision.
A gateway routes model traffic, and many current gateways also add guardrails, identity, and budgets. Guardrails are the policy layer that checks what the traffic contains, such as PII, injections, topics, and spend, whether they run inside a gateway or beside it.
Governance sets policy, ownership, and oversight, and governance platforms may focus primarily on policy, inventory, and oversight rather than inline enforcement. Guardrails enforce those rules on live requests and record the evidence.
They reduce exposure but cannot catch every attempt. Keep output validation and adversarial testing in the program, and treat model output as untrusted input.
Some do, and many cover only pasted text. Test multi-page files and regional identifiers on your own samples, and ask what the platform missed.
Yes. LLM guardrails check prompts and responses, while agent guardrails also control tools and actions through allowlists, identity inheritance, and approval gates.
Open source suits teams with engineers who can run and tune it. Commercial platforms suit teams that want governance, support, and reporting without building them.
Inspection adds some processing time, and the amount depends on the product and your traffic. Measure latency and false positives on your own prompts before you commit.
Employees will use AI with or without approval, so give them a governed path. AI Guardian builds in redaction, approved models, spend limits, and audit evidence, and your risk, IT, and finance leaders see every request in one place. Book a demo to see it run on your own sample prompt.
Listed on Microsoft Marketplace. ISO 27001 certified. 20+ years and 950+ projects delivered. Same-day response.
Written by the Folio3 AI Editorial Team. Technical content on guardrail types, frameworks, and controls was reviewed by Abdul Sami, Head of AI Development at Folio3 AI, in October 2026.
Fill the form below or Contact us at +1 408 365-4638 / email us via contact@folio3.ai
Years of Engineering Excellence
Projects Delivered Worldwide
Client Satisfaction
Build | Govern | Scale
Response Guaranteed
+1 408 365-4638
contact@folio3.ai
6701 Koll Center Parkway, #250 Pleasanton, CA 94566