Specs, stack & features.

Most of what goes wrong with AI agents would have been caught by one question, asked before anyone handed anything over: which of your coworkers has the run of everything? None of them, and not because they are new or unproven. Access follows the job, so the engineer nine years in still cannot touch payroll, and nobody at all gets a copy of the admin's password. Yet that is roughly what an agent gets when it is handed a human's credentials and pointed at a fleet: more reach than anyone it works alongside, and no line of its own in the log.

The fix is not a smarter agent. It is the same arrangement you already use for people, applied to something that is not one. An agent gets its own account, its own scope, and its own line in the record. Then you can stop worrying about what it might decide to do, because the answer is the same as it is for anyone else here: whatever you granted, and nothing beyond it.

The shape of it. An agent account will be a principal type of its own in the directory, alongside people, groups, and hosts. It will authenticate with short-lived certificates like everything else, be governed by the same deny-by-default Rego, and land in the same append-only audit chain. Nothing about it is a separate system running beside the real one. It is the same machinery, with a subject that is understood not to be a person, and a set of doors that stay shut for exactly that reason.

It is also not an AI product. adamance ships no model, calls no API, and runs no inference. It issues the account and holds the boundary. Which agent you run on the other side of that boundary is entirely your business.

Why it is enforced rather than asked. An agent reads things. Tickets, log lines, config files, web pages, whatever you point it at, and some of that was written by somebody else. Sooner or later one of those somebodies will try to talk your agent into doing something you never asked for, and an agent that has been talked into it will ask politely and mean it.

So none of these boundaries are instructions in a prompt. They are the same checks on the same hosts that decide whether a person may run sudo, evaluated before anything happens and enforced locally whether or not the server is reachable. Nothing an agent reads can widen what it is allowed to do. The worst case for a hijacked agent is that it does, badly, the small set of things it was already permitted to do, on the handful of machines it was already scoped to, with the session on record.

Bring your own agent. Whatever you are running is fine: a coding agent on your laptop, a scheduled job that patches servers overnight, an in-house script with a model behind it, or whichever framework is fashionable that month. It will authenticate the way everything else does, and be governed the way everything else is. Nothing about adamance assumes a particular vendor, and nothing needs to reach the internet for any of it to work.

And here is the limit. This governs what an agent can reach and what it can do once it gets there. It does not make an agent competent. Give it a broad grant and it can do broad damage inside that grant, quickly, and the audit trail will show you exactly how. Scope is a tool for making mistakes small, not for making them impossible, and it repays being mean with it.

Each event carries a sequence number, the hash of the entry before it, and an HMAC-SHA256 computed over that sequence number, that previous hash, and the canonical form of the event itself. Alter one field in one row and its hash stops matching, and so does every entry that follows it. Delete a row instead and you leave a gap in a sequence that is unique and monotonic, so the absence is exactly as visible as the edit would have been.

Append-only is not a convention anyone has to honour here. The database enforces it: a trigger rejects UPDATE, DELETE and TRUNCATE outright, sitting behind a runtime role that was never granted them in the first place. Two independent things have to fail before the application can rewrite a row, and anyone reaching past both is someone with administrator rights on the database itself, which the chain and the off-box copy are there to catch. That trigger is exercised in CI against a real Postgres on every run, rather than a mock that agrees with whatever it is told.

Sending copies off the box is optional, and off until you point it at a destination. Turn it on and they leave on a timer, to somewhere the box does not control: external storage you own, write-once WORM hardware, a git repository, an email account, or over SSH or SCP to any machine you can reach, a NAS or a spare box on your own network included. It is not only the audit chain that can travel, either. Full system logs and firewall logs go the same way, on the same timer, signed the same way, so the forensic picture of an incident survives the machine as completely as the audit trail does.

Someone who takes the entire machine has not taken the audit chain and logs that already left it. To reach those they would need your infrastructure and your git host, or your mailbox, or the box in your cupboard, which is not one breach but two unrelated ones. A copy stays verifiable wherever it lands, so a destination has to be reachable rather than trusted. Verification runs continuously against the anchored head, so a break surfaces instead of sitting unnoticed, and there is a runbook for the morning it does.

This detects tampering. It does not prevent it. Someone with the box can still destroy what is on the box. That limit is stated in the threat model rather than left for you to find. The design accepts that and puts the evidence somewhere else instead of pretending the local copy is unbreakable.

The failure this removes is the silent one. Somebody adds an endpoint, wires up the handler, and does not add the policy that decides who may call it. Nothing errors. The route works perfectly. It works for everybody. That mistake does not surface in a test run or a code review, because every line anyone wrote is correct, and it is the missing line that is wrong.

So the server does not rely on anyone remembering. At startup it walks every route that is meant to be gated, confirms a real policy decision sits behind each one, and aborts the boot if any route is unbacked, naming the route it could not find a policy for. An endpoint with no authorization cannot reach production by accident, because the server carrying it does not come up.

Behind that check sit more than two thousand tests over the policy code that makes the decisions, run on every change. Beside them are contract tests whose entire purpose is catching two layers that have quietly stopped agreeing about the same rule, which is the other way a gate stops meaning what you assume it means.

Where the check stops. It proves a route is wired to a policy. It does not prove the policy is the one you intended. A rule that decides the wrong thing will pass every test that agrees with it. What this removes is an entire class of accident, not the work of deciding what the rule ought to say.

Running six good tools usually means learning six admin panels and remembering which one owns what. That is the tax adamance exists to remove. Most settings you will touch are in the adamance console, in one place, and changing one there is a single action rather than a trip through somebody else's interface.

Underneath, the console talks to one API, and that API does the talking to FreeIPA, Keycloak, OPA, step-ca, OpenBao and the rest. You are not holding six sets of credentials or keeping six mental maps.

And past what the console covers, nothing is walled off. Every setting FreeIPA has is still FreeIPA's, and still yours. Same for the others. They are running on your hardware, configured the way their own documentation describes, and adamance does not take that away or wrap it in something you have to go through.

So you are never waiting on us to expose a switch. You go to the tool and set it there, the way you would if you were running it yourself, because you are. A wrapper that quietly narrows what the thing underneath can do eventually stands between you and fixing your own system.

Most companies that run Linux also run Active Directory, and nobody wants a second directory to keep up to date. Already have Active Directory? Keep it: adamance is being built to sit alongside the one you have rather than replace it.

It takes real setup, once. Joining the two directories takes a bit of deliberate work up front, by someone with domain admin rights, and it does mean a change on the AD side rather than a setting inside adamance. You do it once, and after that everything below happens automatically. What it involves is at the bottom of this section.

Nothing gets copied. adamance won't mirror your users, import your directory, or keep a second copy of anyone's password. There is no nightly job to drift out of date. Active Directory stays the one source of truth, and adamance asks it a question at the moment someone tries to do something.

It arrives in two steps. First signing in, where AD accounts log into the adamance console directly. Then the full trust, where an AD user resolves as a real identity on every managed Linux host without ever being given a separate Linux account.

Access rules are only reassuring if you can check them, so adamance lets you ask a straight question and get a straight answer: if this person, on that machine, tried to do this thing, what happens?

You fill in three things: the person, the machine, and the action. Alice from the operators group, say, on the web server, restarting a service with sudo. The verdict comes back allowed or refused, with the reason your rules produced it.

Two obvious uses. Check what your rules really say before you hand somebody access, rather than finding out afterwards. And when a person swears they should have been let in, ask the same question they asked and read the reason back.

Nothing you ask here changes anything. Nobody is granted access, no machine is told about it, and the question is not filed away as though someone really tried it. It is a what-if, and it stays one.

The same goes for a rule you are still writing. Try it against a made-up situation and see what it would do, in a sandbox that is kept well away from the rules your machines are actually enforcing. A mistake gets caught while it is still a draft, instead of after it has reached your fleet.

The actions that carry real risk ask for a second factor at the moment you take them, whether or not you are already signed in. A stolen session is worth a lot less when the thing worth stealing needs proof again on the way out.

Which actions count is not a judgement the console makes on the day. Every operation that carries real risk is marked in the policy itself as needing a fresh factor, so the list is the same for everybody and changing it is a policy change you can read.

Admin also does not have to be permanent. You can request it for a window and let it expire on its own rather than remembering to take it back, which is the arrangement to pick if more than one person has the keys. It is deliberately not forced: one person testing on their own machine should not have to build an approval chain to use their own server.

Two people, where it matters. Dual-control is a policy setting rather than a module you install. Mark an action as needing a second approver and the grant waits until somebody other than the requester signs it off.

The other half of the after-v1 work, and a separate thing from Active Directory interop above: that one is about talking to a Microsoft AD you already run, this one is about tying many adamance instances into one organization. A whole tree of realms under a single governance model, the way enterprise Active Directory has worked for decades. Designed in full, not built yet.

The shape of it. A realm is one adamance installation with its own directory and its own certificate authority, usually one site or one business unit. A forest is a group of realms sharing a namespace: one root realm, child realms beneath it, two-way trust between them from the moment a child is created. A trust is the declared relationship that lets people in one realm authenticate to machines in another. In Active Directory terms a forest is a forest and a realm is a domain, so if you've run AD, you already know the shape.

What it unlocks. Sites in three cities under one root. A subsidiary that keeps its own admins and shares a handful of systems. Contractors from a vendor's forest reaching exactly two machines and nothing else, through a one-way trust that never gives them an account on your side. An acquisition that keeps running its own directory while both sides get on with the work. A lab that shares people with production but stays a separate blast radius. One organization, many realms, one honest answer to who can touch what.

Why it isn't in v1. A trust is a door between two organizations, and a bad one isn't a bug in one install, it's a way into both. Forged cross-realm tickets, transitivity chaining somewhere nobody intended, a foreign admin quietly adding people to a group you granted access to: those are the real failure modes, and each one deserves to be got right slowly. So v1 ships as a single-realm forest, which is the same model with exactly one realm in it. The realm, origin, and forest-root fields are already in the data model, populated and indexed from day one, so switching federation on later is a feature, not a migration.