— How we build
Research informs products. Products test the ideas.
We move from a concrete problem to a model that can be tested, then to software a team can use — and we publish something real at every stage.
— The loop
Three stages, each with a public artifact.
Select a stage to see what it produces and where you can inspect it.
Define the problem
Start from what teams actually hit when agents begin acting, and what current identity, logging and access tools leave unresolved.
WHAT IT PRODUCES
Problem write-ups and executive briefings
— Design constraints
Rules we hold the product to.
These come from the AGF specifications. They are not values-statement filler — each one changes how AXIS is built.
01
The resource owner decides
Whoever owns a resource has the final say over what agents may access, regardless of what an agent claims about its own authority.
02
Trust is separate from policy
"Is this request allowed?" and "is this agent trustworthy?" are different questions. Merging them hides compromised-but-authorized agents.
03
Decisions must be auditable
Every decision should be signed, structured and replayable — because you cannot debug or contest a decision that leaves no trace.
04
Expiration by default
Permissions should decay unless renewed. Short-lived grants create natural checkpoints for re-evaluation.
— An example from our work
From an open model to a running product.
AGF · OPEN
AAP, the Agent Authorization Protocol
Delegation chains, trust zones, revocation and audit, published as an open specification that anyone can implement.
AXIS · PRODUCT
A running authorization service
INTREXA's implementation of that protocol: a service any team can call, built on rules anyone can read.
— Go deeper