Skip to content

Runtime authorization for MCP

Your AI agents act.Axyra decides what they’re allowed to do.

Every tool call your agents make is authorized or blocked in real time, before it reaches your systems. Each decision is kept as proof you can verify.

Let’s talkSee how it works
  • Built for MCP
  • SaaS or on-premises
  • Hash-chained audit trail

0 decisions·0 blocked

The problem

Agents no longer wait for you.

They have the keys to your tools. Who they are gets checked; what they do, rarely.

  • They act on their own

    Agents query databases, write files and run commands, often without asking first.

    db.query · fs.write · shell.exec

  • MCP connects them to everything

    One standard protocol gives them a way into every tool you connect.

    one protocol → every tool

  • One token, all the access

    Scope is granted once, not call by call. A hidden instruction in a GitHub issue was enough to leak private repos.

    token: access to all repos

Why it matters

Your agents act on your behalf. Every action should be authorized, enforced and provable.

How it works

From identity to proof, on every call.

Follow a coding agent working for Anna on the platform team. It tries to write outside its workspace.

01 / 05

Identity

Who is calling?

Each agent carries its own verifiable identity, not a shared API key.

ci-bot

Protected by Axyra

What Axyra sees at this step

agent
ci-bot
issuer
acme identity provider
key
ed25519 · 7f3c…b1e9

Use cases

One gate for every agent you run.

Whatever the agent and whatever the tool, the same rules apply.

  • Coding agents

    Let them write code in the workspace, but never touch your system files.

    fs.write /etc/hostsdeny

  • Support assistants

    Let them answer customers without exporting your CRM.

    crm.export all contactsdeny

  • Data agents

    Let them query what they need, never the columns they shouldn’t.

    db.query orders (read)allow

  • Ops agents

    Let them run the playbook, not arbitrary shell commands.

    shell.exec curl … | shdeny

  • Any MCP server

    Axyra sits in front of the servers you already use. Your tools don’t change.

    • db.query
    • fs.write
    • git.push
    • crm.lookup
    • kb.search
    • shell.exec

Proof

A record you can check, not a log you have to trust.

Each decision is hashed together with the one before it. Change a single record and every link after it breaks. Try it!

decision-log

Protected by Axyra

pausedSample data

Decisions
7
Allowed
5
Blocked
2
Chain head
998959da…df7b
signed head · ed25519
  1. 14:02:14.410allowdb.query

    invoices (read) · read-only-analytics

    #4807 hash 998959da…df7b ← prev 55917b06…480e

  2. 14:02:12.780allowgit.push

    fix/auth-timeout · repo-write

    #4806 hash 55917b06…480e ← prev 0eeb66a1…9cd9

  3. 14:02:12.310denyshell.exec

    curl … | sh · not in delegated scope

    #4805 hash 0eeb66a1…9cd9 ← prev 729c2410…ffe8

  4. 14:02:11.400allowcrm.update

    ticket 88213 · status · support-write

    #4804 hash 729c2410…ffe8 ← prev 380b135f…fbfd

  5. 14:02:09.350denydb.execute

    DROP TABLE staging · write not delegated

    #4803 hash 380b135f…fbfd ← prev 7b77629a…e4c6

  6. 14:02:08.970allowfs.write

    /workspace/fix.patch · workspace-only

    #4802 hash 7b77629a…e4c6 ← prev 71383491…ddb9

  7. 14:02:07.760allowdb.query

    orders (read) · read-only-analytics

    #4801 hash 71383491…ddb9 ← prev 00000000…0000

Try it: tamper with a record, then verify the chain.

Deployment

Run it our way or yours.

Two ways to deploy, with the same gate, the same policies and the same proof.

SaaS

We operate it. You point your agents at a gateway endpoint.

your perimeterYour agents
Axyra cloud
your perimeterYour MCP servers
  • No infrastructure to run or patch
  • Updates and scaling handled for you
  • Decision records exportable to your SIEM

On-premises

You run it inside your own perimeter.

your perimeter
Your agents
Axyra gate
Your MCP servers
  • Deployed as containers in your environment
  • Decisions and records stay on your network
  • Connects to your existing identity provider

Security

Built to be audited, not trusted blindly.

What your security team will ask, answered by design.

  • Verifiable by design

    Every decision is hash-chained, and the chain head is signed. Your auditors verify the ledger themselves with a public key, without relying on us.

  • You control the data

    Choose where decision records live. On-premises, nothing leaves your perimeter.

  • Policies you can read

    Policies are code: reviewed, versioned and tested like the rest of your stack.

  • Least privilege by default

    An agent gets only what a person delegated, for a limited time. Anything else is blocked.

Want to go through the architecture with an engineer?

Let’s talk

Put a gate between your agents and your tools.

We start with a security audit of your environment, followed by a concrete remediation plan.

Let’s talkcontact@axyra.fr