The policy each customer requires, on every request.

Policy per customer

Your customers are named on each request by your own identifiers. Policies select them, and every policy that matches applies.

• A policy matches by organization, user or plan, or by their absence: a request with no organization can be matched too.
• Guardrails, limits and retention take the strictest value any matching policy sets, so adding a policy never loosens them.
• Regions, models and connections are lists. A request starts with its own model, the environment’s region and the connections that can serve it. Each matching policy can add to a list, keep only some of it, or remove some: every add counts first, then every only and remove, so a customer’s “only the EU” can’t be undone by a plan’s add. A policy can’t add a model.
• When a list ends up empty, the request is refused. In a US environment, a policy that keeps only the EU refuses every request it matches unless some policy, perhaps itself, adds the EU.
• A guardrail warns, recording each finding and changing nothing, or acts on it: pseudonymizes, redacts, blocks or cuts. A guardrail set by several policies takes the strongest action. Start with warn, look at the findings, then act.
• Replay a draft policy against past requests before saving it. With retained content the guardrails replay too; without it, the routing settings do.
• Every version of every policy is kept, and each request records the versions it ran.

Guardrails

Guardrails inspect the parts of a request you choose: the system prompt, user and assistant turns, tool calls and tool results.

Every check runs in the gateway, with no model call. The guardrails page has how accurate each one is, measured on public datasets, how each fails, and what it may cost in latency.

• Content nothing can inspect, such as an image, is recorded as uninspected, or blocked if the policy says so. A verdict never claims more than its coverage.
• A block that’s resent in the next turn is scanned once, and its findings are counted once.
• Signed or encrypted reasoning from a provider passes through byte for byte.

Regions and routing

Each region runs a full copy of Alectura, and an environment is pinned to one when it’s created. TLS ends there, inspection and edits happen there, and everything kept about the traffic stays there.

A request goes to a provider of its own format, and no format is ever translated into another:

• A request may be served by the environment’s connections and by its organization’s own, which go first within their region. Policies add, keep only or remove provider regions and connections, and can number what they add: lower numbers are tried first, then unnumbered ones, and ties are picked at random.
• A failure before the provider’s first byte moves the request to the next candidate, for up to three attempts. A connection that keeps failing cools down and is skipped.
• Region, model and retention constraints fail closed: when nothing allowed can serve a request, it’s refused, never sent somewhere else.
• Every attempt is recorded, with the region that served it.

Models and retention

Allow the models each customer approved, choose whose connections serve it, and keep only what it lets you keep.

• A policy keeps only the models a request may use, or removes some. An id without a date matches every dated version of it, on every provider that serves it.
• Each connection declares its provider’s data terms: whether the provider retains content, and whether it trains on it. Undeclared counts as retaining.
• Content is kept for none, 7, 30, 90 or 365 days, per policy. With none, a request to OpenAI says store: false, so OpenAI doesn’t keep the response to retrieve later; its abuse monitoring still keeps data unless your OpenAI account has zero retention.
• With zero retention, Alectura keeps verdicts, counts and keyed hashes, and never content. Records are kept 400 days whatever the content’s retention.
• Each organization’s content is sealed with its own key, so deleting the organization makes its content unreadable at once.

Limits

Rate, token and spend limits, per user or per organization, so no plan can cost more than it earns.

"limit": {
  "kind": "spend",
  "per": "user",
  "period": "day",
  "amount": "2.00",
  "used": "1.9962",
  "requested": "0.0079",
  "resets_at": "2026-09-30T00:00:00Z"
}

Abuse

Abuse of a free tier shows across requests, not in any one of them. Alectura attributes every request to a user and watches for the patterns.

• Signals are observations drawn from many requests, per user and per organization, each with a score and the requests behind it: repeated injection attempts, probing for secrets, a template shared between accounts.
• Suspend a user or an organization by hand, or let a policy suspend a user when a signal’s score reaches the threshold you set. Every gateway refuses them within 10 seconds.
• A request that names a user or an organization reaches OpenAI, Anthropic and Bedrock with a safety identifier: a keyed hash of the user, or of the organization when there is no user. When a provider acts on abuse, it acts on one of your users, not your whole account. Gemini’s API has no such field, so it gets none.
• Assessments: upload request logs in OpenAI’s Chat Completions or Responses format, Anthropic’s Messages, Gemini’s generateContent or Bedrock’s invocation logs, or just each request’s metadata as JSONL or CSV, and get back a report on the users that look abusive.

Evidence

The answer to the AI section of a security questionnaire, per customer, from what actually happened.

Events and webhooks

What happens in an environment is an event, listed by the API and delivered to your endpoints, so your product can act on it.

• Each delivery is signed with HMAC-SHA256 in Alectura-Signature, with a timestamp, and carries a delivery id that stays the same across retries.
• A delivery that fails is tried again after 1 minute, 10 minutes, 1 hour and 12 hours.
• A rotated secret signs alongside the old one for 24 hours.

Dashboard

Everything above, for every environment, at app.alecturalabs.com. Sign in with an email link, Google or Microsoft, or your team’s SSO.

Roles decide who sees what: admins manage the team, developers configure, viewers read. The dashboard runs on the management API, which your own scripts can call too.