Operanta Agent Security Platform —
Operanta Agent Security Platform

The Security & Evidence layer for AI in finance..

Operanta secures every AI request through a verification pipeline of deterministic gates — and returns a signed, regulator-ready Evidence Pack.Operanta secures every AI request through a verification pipeline of deterministic gates — and returns a signed, replayable record of the decision.

Trust the gates, not the model.

See how it works ↓
The problem

An LLM cannot be made auditable enough for a financial regulator.

Two things break at once — and they’re the two questions a regulator actually asks.

A — Security

Can you trust what it did?

The failure surface is broad and structural:

  • Prompt injection — hidden text becomes instructions the model follows.
  • Hallucination — it fabricates facts with no signal that it did.
  • Non-determinism — the same input gives different outputs; the same audit can’t be reproduced.
  • Poisoning — defects baked in upstream at the vendor, invisible to you.

The EU AI Act, Article 15(5), names five cybersecurity threats to high-risk AI — different in shape, identical in trust assumption: you cannot audit what is inside the model.

B — Evidence

Can you prove why it decided?

Every decision is one a regulator can make you justify:

  • The reason — why the system approved this customer, flagged this transaction, declined this credit.
  • Reproducible — the same decision re-derived after the fact, on demand, sometimes months later.
  • As proof, not a log — a record of what happened doesn’t show why it was allowed.
  • Mapped to the rule — tied to the specific DORA, EU AI Act, or MiCA article you answer to.

Across these frameworks the burden is identical: show the reason behind each decision. A well-aligned model isn’t an answer.

Myth-buster

Running on AI doesn’t make you compliant. Every defence built inside the model — alignment, RLHF, guardrails, system prompts — lowers a probability; none proves a bound. And a probability is neither security a CISO can sign nor evidence a regulator accepts.

The problem

The moment your AI can call tools and touch data, two things break — and neither is solvable inside the model.

One is an attack you can’t patch. The other is a question you can’t answer.

A — Security

Can you keep it from being hijacked?

The failure surface is broad and structural:

  • Prompt injection — hidden text in a document, a web page, or a tool response becomes instructions the model follows.
  • Tool misuse — a manipulated model calls the wrong tool, hits the wrong endpoint, or moves data it shouldn’t.
  • Non-determinism — the same input gives different outputs; the run you reviewed isn’t the run that ships.
  • Poisoning — defects baked in upstream at the vendor, invisible to you.

Different in shape, identical in trust assumption: you cannot secure what is inside the model from inside the model.

B — Evidence

Can you see why it did what it did?

When an agent acts, you need to account for it:

  • The reason — why the agent called this tool, sent this request, returned this answer.
  • Reproducible — the same decision re-derived after the fact, on demand, sometimes long after.
  • As proof, not a log — a record of what happened doesn’t show what was allowed and why it passed.
  • For whoever asks later — your team, an incident, a customer or a partner — anyone who later asks why did it do that.

The model’s own logs don’t prove it, and the next run may differ. A well-aligned model isn’t an answer.

Myth-buster

Running on AI doesn’t make you secure — or accountable. Every defence built inside the model — alignment, RLHF, guardrails, system prompts — lowers a probability; none proves a bound. And a probability is neither security a team can sign off on nor a record you can stand behind.

The position

The only architecturally honest move: treat the model as untrusted by default, put the trust boundary outside it — in deterministic gates you can read line by line — and sign the result. We don’t make the model safe. We make what it can do bounded, and what it did provable. That answers both questions at once.

Trust the gates,
not the model.

How it works

Inline in your perimeter. Verify every request. Sign the proof.

Operanta runs in your own perimeter, right next to your model — inline on the path of every request. It checks each request before the model sees it and each answer before it ships, then seals the decision as a signed record. Not a container, not a sandbox, not a gateway — a layer between your app and your model. The model isn’t a gate: it’s invoked inside the layer, under a control-flow lock.

your perimeter · your server
your productionapp · workflow
OPERANTA · checks & signs7 deterministic gates
01Input screeningData ≠ commands

Every external input is authenticated, schema-validated, and separated from instructions before it reaches the model. Data ≠ commands, at the protocol level.

your AImodel · API
not a container · not a sandbox · not a gateway
signed Evidence Pack
Auditor · verifies offline
your perimeter · your server
your productionapp · workflow
OPERANTA · checks & signs7 deterministic gates
01Input screeningData ≠ commands

Every external input is authenticated, schema-validated, and separated from instructions before it reaches the model. Data ≠ commands, at the protocol level.

your AImodel · API
not a container · not a sandbox · not a gateway
signed decision record
read & replay offline
Why it works when others don’t

Most AI security lowers a probability and hopes. We change the structure.

In two ways a regulator and a CISO can both check.

Move 1

Verified before execution, not filtered after.

The checks and the capability lock run before the model acts. The decisions that govern execution — which tool, which endpoint, which tenant — come only from trusted sources, never from the prompt or the model’s output. Untrusted input can pick among already-permitted routes, but can’t introduce a new one — the unsafe path simply isn’t in the set.

A guardrail filters probabilistically and leaks one in a hundred; here the unsafe route is structurally absent — and a gate that can’t run its check blocks the action rather than guessing.

Move 2

Signed evidence by default, not logs after the fact.

Every decision produces a tamper-evident, offline-verifiable Evidence Pack — sealed as the decision is made, not reconstructed later from logs. It carries the checks that ran, the policy that governed them, and a proof it wasn’t altered after the fact, all mapped to the specific regulator article you answer to.

A log records what happened and proves nothing. An attestation vendor signs the output — but never verified it before the action.

No one has the whole: verification before execution + capability control of the flow + signed evidence + fintech regulation covered as one — over any model, in your own perimeter.

What this lets you do
Let AI into regulated workflows without opening a new attack surface
Process untrusted documents — KYC packets, attachments — without assuming they’re clean
Swap the model without re-auditing the controls
Stay sovereign by design — it runs on your own server, and the evidence never leaves

The agent can go where you wouldn’t deploy it today.

Why it works when others don’t

Most AI security lowers a probability and hopes. We change the structure.

In two ways your security and platform teams can both check.

Move 1

Verified before execution, not filtered after.

The checks and the capability lock run before the model acts. The decisions that govern execution — which tool, which endpoint, which tenant — come only from trusted sources, never from the prompt or the model’s output. Untrusted input can pick among already-permitted routes, but can’t introduce a new one — the unsafe path simply isn’t in the set.

A guardrail filters probabilistically and leaks one in a hundred; here the unsafe route is structurally absent — and a gate that can’t run its check blocks the action rather than guessing.

Move 2

A signed record by default, not logs after the fact.

Every decision produces a tamper-evident, offline-verifiable record — sealed as the decision is made, not reconstructed later from logs. It carries the checks that ran, the plan the model proposed, the tools it was permitted, and the output — plus a proof it wasn’t altered after the fact.

An AgentOps tool gives you a trace after the fact; an attestation vendor signs the output alone — but never verified it before the action, and neither ties the record to what was allowed.

No one has the whole: verification before execution + capability control of the flow + a signed, replayable record + one layer over any model — self-hosted or hosted, in your own perimeter.

What this lets you do
Let AI into production without opening a new attack surface
Process untrusted documents — files, web content, attachments — without assuming they’re clean
Swap the model without re-auditing the controls or losing the record
Stay sovereign by design — it runs on your own server, and the record never leaves

The agent can go where you wouldn’t deploy it today.

See it

The product, not a promise.

What the layer actually gives your team — you set it up on the platform, then it runs in your own perimeter.

Pick a self-hosted runner or the API you call into, and the inbound port.

Any model behind the layer — self-hosted or an API you call into. One setup per system; it runs entirely in your own perimeter, evidence stays local, and every new build redeploys — so every request and every new agent inside is covered.

See it

The product, not a promise.

What the layer actually gives your team — you set it up on the platform, then it runs in your own perimeter.

Pick a self-hosted runner or the API you call into, and the inbound port.

Any model behind the layer — self-hosted or an API you call into. One setup per system; it runs entirely in your own perimeter, records stays local, and every new build redeploys — so every request and every new agent inside is covered.

Proof, not logs

Evidence a regulator verifies without us.

Every decision leaves a cryptographically signed Evidence Pack: what was checked, by which gate, against which policy, plus an integrity proof it wasn’t altered after the fact. Your regulator verifies it offline, on their own — the vendor-independent trail DORA Article 28/29 concentration-risk asks for. It’s your proof, not ours.

DORAArt. 17, 18, 19, 25, 28

ICT-incident reporting, third-party register entries, resilience-testing artifacts.

EU AI ActArt. 15(5), Annex IV

Cybersecurity-of-high-risk-AI mappings, technical documentation — much auto-generated from runtime.

MiCAArt. 38, 43, 45

CASP operational governance and conduct evidence.

SAMACyber Security Framework · Phase 3

KSA-domiciled banking control evidence.

A record, not a log.

A record you replay — not a log you hope is right.

Every decision leaves a signed record: what was checked, by which gate, against which policy, what the model proposed, and what it was allowed to do — plus an integrity proof it wasn’t altered after the fact. Replay it offline, on your own, with the public key inside it. When someone asks why the AI did what it did, you don’t argue with the model’s logs — you replay the record. It’s your record, not ours.

Checks run

Which verifiers ran on the input and the output, and what they found.

Plan proposed

What the model actually proposed, before it was interpreted.

Tools permitted

The capabilities granted from trusted sources for this run.

Output + integrity

The final result, signed, with a proof the run wasn’t altered or reordered.

See a signed Evidence Pack on your own workflow.

Bring a model and a request you actually run — we’ll walk the pipeline and the proof end to end, and tell you straight where Operanta fits and where it doesn’t.

Or email us: [email protected]

See a signed decision record on your own workflow.

Bring a model and a request you actually run — we’ll walk the pipeline and the proof end to end, and tell you straight where Operanta fits and where it doesn’t. No deck required.

Or email us: [email protected]