05 ·Agnidoot Gateway· Enterprise

Who uses AI. When. How much.
And what they send it.

Your people are already using AI, and nobody can tell you what it costs, what's being sent out of the building, or whether any of it is worth the money. Gateway is the control plane and the observability platform that answers all three — enforced at the server, where an application cannot argue with it.

Who & when Budget per person and team Every request inspected Every request priced
100%

Of requests priced
and attributed to a person

7,263

Requests refused
before reaching a model

0

Ordinary prompts stored
hash and lengths only

30d

Then blocked content
is erased automatically

The problem

Nobody banned AI. Nobody controls it either.

In most companies of 50–500 people, staff started using AI on their own. The tools are useful, so nobody wants to switch them off — but three questions have no answer, and they're the three a finance director and a security officer will both ask.

Cost

"How much are we spending, and on what?"

Subscriptions on personal cards, API keys in a dozen projects, no line item anyone can defend at a board meeting.

Exposure

"What are people actually sending?"

A customer contract pasted into a chat window. A spreadsheet with card numbers. Nobody finds out, because nothing is watching.

Return

"Is any of it worth it?"

Spend with no attribution can't be judged. Which team, which use, which model — without that, ROI is a guess.

Gateway's answer isn't "ban it". It's to put every AI request in your organisation through one governed path — so the tools your people already like keep working, and you get control, cost attribution and an audit trail as a side effect.

Four questions, four controls

Who · When · How much · What.

Each is enforced server-side. A client cannot negotiate with any of them, because the decision is made before the request reaches a model.

01

WHO — access, by person and by team

AI access becomes a permission you grant, not a tool people find for themselves. Identity comes from your own provider, so joiners and leavers are handled where you already handle them.

  • Your identity provider, end to end — real SSO, verified live
  • Forged, expired and untrusted tokens refused
  • Remove someone at the directory and their AI access goes with it
  • Teams carry their own policy — model, guardrails, channels, tools
  • Per-person attribution on every single request
  • An outage never locks anyone out — sessions survive, local sign-in is a separate door
02

WHEN — AI on a schedule you set

An unusual control, and a genuinely useful one: budgets carry day-of-week and time-of-day windows, enforced timezone-aware. AI can be available during working hours and simply unavailable outside them.

  • Allowed days — weekdays only, if that's your policy
  • Allowed hours — a start and end time per window
  • Timezone-aware, so a global team behaves correctly
  • Enforced server-side, not a reminder in a handbook
  • Different windows per team — support around the clock, marketing nine to five

Why it matters: out-of-hours automated traffic is where runaway spend usually happens — a loop nobody notices until the invoice. A window closes that door without anyone having to watch for it.

03

HOW MUCH — granular budgets, and a graceful stop

Spend caps at the level you actually manage money: the organisation as a whole, and each individual person. Teams carry their own policy alongside. When a cap is reached, work stops cleanly.

  • Per organisation — a hard ceiling for the whole tenant
  • Per person — so one user's automation can't drain the pool
  • By month or custom period, with schedules attached
  • Caps from one cent upward — small enough to pilot with
  • A humane refusal — "your organisation's AI budget for this period has been used up… your administrator can raise the limit"
  • The admin sees which team spent it
  • Unpriced models are refused outright, so spend can never be untracked
04

WHAT — every request inspected before it leaves

This is the control that stops the incident. Each request is checked against your policy before any model sees the content — so sensitive material never leaves the building at all, rather than being discovered in a log afterwards.

  • Refused pre-model — the content is stopped, not merely recorded
  • Scope-of-use classification — off-policy requests blocked
  • Your own keywords and patterns — card formats, account numbers, project code names
  • Category rules per tenant
  • PII and prompt-injection detection available to configure
  • Your own block message, so the person understands why
  • The attempt is recorded so a manager can have a conversation

Proven at volume: on our own stack this gate has refused 7,263 requests — every one of them stopped before a model was called.

Full observability

Every AI request in your organisation, on one record.

Control without measurement is a policy document. Every request that passes through Gateway — allowed or refused — leaves a row you can query, attribute and export.

What is captured, per request

The full record

  • Who — the person, and their team
  • What model actually served it
  • Tokens in and out
  • Cost, priced at the point of use
  • Latency and status
  • Outcome — served, refused, or over budget
What you can answer with it

The questions behind ROI

  • What did AI cost us this month, by team and by person
  • Which use cases consume the budget
  • Which models are worth their price
  • What was refused, and why
  • Who is actually using it — and who isn't
  • Is spend rising or flattening against output
One correlation ID joins the conversation, the document, the ERP write and the configuration change into a single timeline.
Refusals are recorded too — "the platform stopped this" is provable, not silent.
Blocked content is reviewable — an administrator can see exactly what someone tried to send.
Then erased automatically after 30 days, with the record of the block retained.
Role-scoped visibility — a trail never becomes a way to read a colleague's activity.
Streams to your SIEM, on your own infrastructure.
On cost reporting — read this before you plan around it

The data is complete; the packaged dashboards are not. Every request is priced and attributed, and that record is queryable and exportable today — so cost-per-team and cost-per-person are answerable right now.

What we deliberately do not ship is the built-in cost dashboard. An earlier version of it returned plausible invented figures behind real authentication, so we disabled it rather than let anyone make a budget decision on a number the system made up. It returns an explicit "not available" until the analytics are wired properly. Given what this product is for, we'd rather hand you nothing than something untrue.

Privacy

Monitoring everything, storing almost nothing.

Observability usually means retention, and retention is its own liability. Here it doesn't: every request is inspected and measured, and ordinary prompt text is never kept.

Ordinary prompt text is never stored. A one-way hash, the request length and the response length. No column holds the content.
Prompts are not indexed or embedded. Search and vector indexing are pinned off in tracked configuration, not left to a default.
Only blocked content is kept — deliberately, so an administrator can review what was attempted — and it is erased after 30 days.
Run it entirely local. Point the models at the AI-ready box in your building and nothing leaves your walls at all.
Record values stay local. The audit stream that leaves the machine carries field names only.
Skills are audited on import — verified live: prompt-injection and shell-execution patterns in bundled skills were blocked.

The details

Questions a security or finance review will ask.

Can we stop someone sending card numbers or personal data?Data loss

The gate is real, server-side and proven at volume — 7,263 requests refused before reaching a model on our own stack. It refuses rather than redacts, so nothing sensitive leaves the building.

What you configure into that gate is per tenant: your own keywords and patterns (card formats, account numbers, project code names), category rules, and built-in PII and prompt-injection detection, with a block message you write.

Stated precisely: the enforcement path is verified and carries real traffic. The PII-specific detectors are configuration we have not yet exercised end to end in QA — so we'll configure them on your tenant and demonstrate them against your own patterns during the assessment, rather than ask you to take a data-loss claim on trust.

How granular can budgets get?Cost

Two enforced levels today, plus scheduling on each:

  • Per organisation — one ceiling for the whole tenant.
  • Per person — an individual cap, so one runaway automation can't consume everyone's budget.
  • Per period — monthly or a custom window.
  • Per schedule — allowed days and hours on any budget, timezone-aware.

Teams sit alongside this, carrying their own policy — model, guardrails, permitted tools and channels — and every request is attributed to a person and their team, so cost by team is answerable from the record even where the enforced cap is set per person. If you need a hard cap enforced at team level specifically, raise it in the assessment and we'll be straight about where that sits.

What exactly happens when a limit is hit?Behaviour

The AI step halts and the person sees a plain sentence: "Your organisation's AI budget for this period has been used up… your administrator can raise the limit." No error code, no stack trace. Work stops cleanly, nobody's card is surprised, and the administrator can see which team spent it.

A request outside an allowed time window, or outside permitted use, is refused the same way — before a model is called, with the attempt recorded.

How does per-person Odoo identity work?Identity

The identity hub proves who is calling — an OIDC token verified against the hub's live signing keys. The bridge then maps that identity to a credential it already holds, so a durable Odoo API key never travels over the network.

Verified against a live hub: a real token for a registered person resolved to their own Odoo login; a token for an unregistered person failed closed; and the shared service credential was unreachable in both paths.

The honest cost: an administrator registers each person's Odoo login once. It isn't zero-config.

Teams, workspaces and permissionsStructure
  • Teams and membership, each with policy — model alias, guardrails, messaging channels, permitted tools, audit requirements.
  • Workspaces shareable with a person, a team or a group, each carrying a permission level.
  • Groups, with directory sync from your identity hub.
  • Skills and skill groups granted per team, audited on import.

Read this carefully before you design your teams: a person in two teams receives the union of both teams' capabilities, not the intersection. Adding someone to a second team widens their access.

How does it sit next to the rest of the platform?Architecture

Gateway governs beside the execution path, never in front of it. No Odoo request is routed through a Gateway process. AI traffic flows through it for model, budget, schedule and policy; identity comes from the hub; the bridge emits usage and audit to it. Approvals, risk tiers and the ERP write path stay exactly where they were.

That was deliberate: the bridge models more about an ERP action than a general AI gateway can, so execution stays with the component that understands it. Governance is added, never substituted.

What happens if we turn Gateway off?Reversibility

The platform behaves byte-for-byte as it did before the tier existed. That is the acceptance criterion for the whole enterprise tier, and proving it is itself a test case in our QA suite. Upgrading — and downgrading — is a decision, not a migration.

What we will not claim

No penetration test and no compliance certification (SOC 2, ISO) has been performed. Claims about what is stored are verifiable from the schema and are made above; claims about what is secure we don't make. We'll hand your security tester the code instead of a PDF.

Four specifics a careful buyer should know: capability and tool policy is client-enforced, not server-side authorization — real authorization lives in entitlement and in the bridge's risk tiers; team permissions union rather than intersect; packaged cost dashboards are disabled for the reason given above; and there is no request rate limiting on the gateway endpoint yet — budgets and schedules are the spend control, not throttling.

We also don't offer sentiment or tone analysis of your team's AI conversations. It isn't built — and given that ordinary prompt text is never stored, it would mean reversing the privacy property this page is built on. If monitoring communication tone is a requirement, tell us and we'll say plainly whether it's something we'd build.

Every plan includes

Try it free for three months. Keep the support for a year.

No obligation, no card, no lock-in. And what comes with your plan isn't a discount — it's what it takes to make an ERP actually land.

Start free →
Weeks

Start in weeks

Not months. Your implementation is underway in your first week.

1 year

Free support

A full year included with every plan — not a paid add-on.

On-site

Training included

We come to you and train your team in the room, on your data.

100 hrs

Customisation

A hundred hours of our engineering, built into every plan.

No card to start  ·  No obligation  ·  Cancel any time in the three months  ·  Your data stays yours

Questions

The rest of the governance questions.

What the gateway is for

What problem does the gateway solve?
Nobody in your company banned AI, and nobody controls it either. The gateway makes every AI request in the organisation pass one point — so you can say who may use it, for what, how much, and prove afterwards what happened.
What can we actually control?
Which people and teams may use AI, which models they reach, what they may spend, what they may touch in Odoo, and which actions need approval before they run.
Do we get to see what AI is costing us?
Every request is priced and attributed to a person, a team and a purpose. Cost stops being one unexplained monthly invoice and becomes a line you can question.
Does this slow people down?
Only where you want it to. Reads and low-risk work run normally; the friction is placed deliberately on the actions that change money or data.

How it works technically

How does routing across model providers work?
Ten providers are supported. You set the policy — which model a given team or workload uses — and the gateway routes accordingly, so changing provider is a configuration decision rather than a rebuild.
What exactly is in the audit trail?
One correlation ID ties together the person, the request, the retrieval, the model, the cost and the Odoo change. You can follow a single business event end to end.
What is stored, and what isn't?
The metadata that proves governance is kept. The prompt content is not retained after a request completes — the gateway monitors everything and stores almost nothing.
Where does it run?
Managed, or entirely inside your own network on Enterprise, where local models are the default and cloud providers are optional.

Getting started

Which edition includes the gateway?
Governed AI access is part of Standard, and Enterprise extends it with private local models, per-person Odoo identity and the full control set.
What is the sensible first policy to set?
Start by making everything visible without blocking anything. Once a month of real usage is on the record, the limits that matter become obvious — and they are rarely the ones people guess.

Bring one month of unexplained AI spend.

We'll route it through Gateway and show you who spent it, on what, and what got stopped on the way out — live, on your own tenant.

Book a demo

See it running on your own documents.

Thirty minutes, your paperwork, your questions. We will show you what it does — and, just as importantly, what it refuses to do.

Book a demo →