Solutions · AI Agent Control
Your newest hires aren't human. Stop lending them your keys.
AI agents already act inside your systems — writing schemas, calling APIs, touching customer data. In most stacks they do it with a borrowed API key, so the log says a person did it and nobody can say what the AI actually touched. Axowl hires an agent the way you hire a person: it gets its own badge , exactly the scopes you grant, a TTL it cannot outlive, and a sealed record of everything — including the moment it was told no .
See pricing Talk to sales
Identity One badge per agent — never a shared key
Authority Zero scopes by default · granted at hire
Lifecycle TTL on every agent · sealed revocation
badge per agent
same identity model as your people and teams
seats consumed
agents bill by what they use, never by headcount
scopes at birth
an agent can do nothing until someone grants it
100%
of refusals on the record
"the AI was blocked" is a sealed event, not a guess
01 · The problem
The agent acted as you. So the log says it was you.
Agent adoption outran agent identity. Most teams wire an LLM to production with a key copied from a developer's environment — and from that moment the platform cannot tell the human from the machine.
Borrowed keys erase the actor
An agent running on a person's API key inherits everything that person can do — and signs the audit trail with their name. When something goes wrong, the question "was that you or the AI?" has no answer, because the system never recorded the difference.
There is no roster
Ask most engineering teams how many agents run against production and the answer is a shrug. They live in cron jobs, notebooks, and side projects — an invisible workforce with no list, no owner, and no review that ever includes them.
Agents don't resign
A person who leaves gets offboarded. An agent whose project ended just keeps its credentials — for months, sometimes years. The most dangerous actor in your system is the one everybody forgot they created.
Architecture
How it actually works
Two claims on this page are structural, not marketing: a machine is never treated as a person, and proving what happened never makes anyone wait. Here is the shape that makes both true.
What happens when an agent tries to change something
Person asks the agent AND gate agent scope ∩ delegating person Allowed change is applied Denied nothing changes Sealed record both outcomes are kept
The gate is an AND , not an OR. An agent can only do what it is allowed to do and what the person who asked it is allowed to do — so nobody can hand a machine authority they do not have themselves. Denials are kept, not discarded: being able to show that something was blocked is the point.
Why proof does not slow anything down
What the user waits for Request Decision Response The answer returns here. Sealing is not on this line. What happens on its own Event bus Seal Hot store recent activity Archive columnar, long term Reports Held until the worker confirms each one — a restart replays what it missed, so nothing is dropped while we deploy.
Cryptographic sealing is expensive — when we measured it inline, it added roughly three quarters of a second to every action. So it moved off the path a user waits on. The record is still written for every action; it is simply written beside the request rather than in front of it.
02 · The roster
Hire an agent team the way you hire a human one.
Every App Group carries an agent roster. You hire from role templates — each one a job description with exactly the scopes that job needs — and each hire mints a new badge. The roster is the answer to "what AI runs here": one screen, per project, with an owner and an expiry on every row.
design
Design agent
Screens and branding. Writes HTML/CSS; can touch the app's look, nothing else.
db
DB agent
Drafts table schemas and queries. Schema create and update — not delete.
api
API agent
Key issuance and webhook wiring — the plumbing that connects outward.
test
Test agent
Verifies scenarios. Read and list only — it structurally cannot write.
custom
Custom agent
Pick scopes yourself. It starts with zero and holds only what you check.
A template is a starting point, not a ceiling — every scope is a checkbox you can untick before the hire lands.
Badge A first-class identity — not a row in a secrets vault
Scopes The agent's toolset is its permission set — nothing more
TTL Born with an expiry — a forgotten agent suspends itself
Seal Hire, denial, and revocation land in a tamper-evident chain
03 · Permit-first
Nothing moves without a permit.
Asking a model nicely to stay in its lane is a prompt, not a control. Axowl enforces the lane in the structure: an agent's authority is whatever its badge holds, checked by the server on every action — regardless of what the model produces.
Refused at grant time, not found at audit time
Permissions attach to the badge through the same role engine your people use — with the same separation-of-duties check, so a toxic combination is refused the moment someone tries to grant it. And one grant is refused categorically: an agent can never hold the permission to hire agents. Machines do not hire machines here.
A tool gate on every write
When an agent produces work — a screen, a schema, a query — the server checks the badge before anything is applied. A denial is not swallowed: it is written into the agent's reply, fed back to the model, and sealed into the audit chain as its own event. "The AI was blocked" becomes evidence, not an anecdote.
The badge
Humans aren't the only things acting in your systems
Every actor in an App Group carries a badge: employees, contractors, external customers, service accounts, and AI agents alike. Permissions attach to the badge rather than to an email address, which is why an agent can hold a narrow, revocable set of scopes and still show up in the same access review as the person who created it.
One badge per actor — human, service, or agent
Teams are principals too, so a team can hold roles of its own
Conflicting combinations are refused at grant time, not found at audit time
Revocation is a sealed event, not a row someone can quietly delete
The real-time transition-sealing architecture underneath is patent-pending (KR 10-2026-0065833, expedited examination).
04 · Lifecycle
Born with an expiry. Retired on the record.
An agent's whole life is a chain of sealed events — hired, granted, blocked, suspended, revoked. There is no path through that life that leaves no trace, and no trace an administrator can quietly rewrite.
Hired
Badge minted, template scopes granted, TTL set — recorded with the person who did the hiring.
Sealed event
Granted & adjusted
Every later widening or narrowing of the agent's authority lands as its own event on its own badge.
Sealed event
Acting — gated
Every action passes the tool gate before it lands — whatever is running the agent. A refusal goes back to the caller and into the chain.
Sealed event
Expired
The TTL arrives and the platform suspends the agent by itself — credentials stop working immediately.
Automatic
Revoked
The roster row is retired, never erased. Revocation is an append-only fact with an actor and a timestamp.
Sealed event
The badge, the gate, the TTL and the sealed record belong to the agent — not to whatever is running it. Axowl grants and enforces the authority; the model on the other end is your choice. If you have no runtime of your own, our console will drive design and DB agents for you, metered per badge and billed by tokens rather than seats — ten agents on a project cost you their work, not ten licenses. The sealing that makes this lifecycle tamper-evident is patent-pending (KR 10-2026-0065833).
05 · The alternative
The same agents. A badge instead of a borrowed key.
Capability
Axowl Agent Control
Borrowed keys + discovery tools
✓ native · △ partial or add-on · ✕ not the model Comparison describes general capabilities of each product category, not any specific commercial offering.
06 · In practice
Three shapes this fits well
A team building with an agent crew
Design, DB, and test agents hired onto one project, each with its own badge and its own lane. The humans direct; the roster shows exactly who — and what — is working, and the test agent can prove it never wrote a thing.
A SaaS product shipping agent features
Your product's agents act on customer data — so each one carries a narrow badge inside the customer's App Group instead of a master key over everything. When a customer asks "what can your AI touch?", the roster is the answer.
A regulated org that must answer for AI
When the review comes, every agent appears in the same access review as its creator — with granted scopes, recorded denials, and a sealed lifecycle. The question "what did the AI do here?" gets an evidence-grade answer.
Give every agent a badge. Keep every "no" on the record.
Tell us what your agents do today — we will map each one to a badge, a template, and a TTL before you hand over a single key.
Talk to sales The structure it lives in