How do you stay in control of many SI agents at once?

A single chatbot answers questions. A multi-agent system is different: many SI agents run for days, read mail, change databases and hand work to each other. Each one acts for a real person or company.

In October 2026 Katelyn Lesse described the new set of problems engineers must solve before such systems can be trusted. She names four areas: infrastructure, identity and permissions, security and isolation, and monitoring with a way to stop the system. We work on the last three.

Today many agents share one static key. If something goes wrong, nobody can say which agent did it or who approved it. We want every agent to have its own identity with short-lived credentials, similar to how SPIFFE gives each service its own identity.

A person should be able to say: this agent may handle my invoices for four weeks, up to a set budget, and nothing else. That approval is a consent grant. It can be revoked at any moment, and every credential built on it stops working. The technical basis is a standard called OAuth 2.0 Token Exchange (RFC 8693).

When one agent passes a task to another, the second agent should only receive part of the first agent's rights, never more. The whole chain stays visible.

Yes, and that is the uncomfortable part. Researchers have shown that text hidden in a web page or an email can steer an SI model, a technique called indirect prompt injection. If that agent writes into a shared memory, other agents may read the planted instruction later.

Our plan is to label every memory entry with who wrote it and where the content came from. Agents can then treat untrusted content as data, and an operator can remove everything a suspicious agent wrote. This reduces the damage. It does not make injection impossible.

Every agent action should go into an audit log that agents cannot edit. Each entry contains a fingerprint of the previous one, so any later change breaks the chain and shows up. This idea goes back to secure audit logs from 1999. Traces use the open OpenTelemetry format, so you can follow one task across many agents.

There should also be one stop control. Pressing it halts all agents of a company, revokes every consent grant and blocks new credentials until a person restarts the system.

Most checks happen while an agent runs, after it has already tried something. With li, our checkable programming language, we want to write down what an agent is allowed to do and let a checker reject rules that could go beyond the approved grant before the agent ever starts.

The proof covers the rules, not the thinking of the SI model. A model can still make bad choices inside its limits. The limits themselves are what we want to make checkable.

Librebase already gives agents access through its MCP server and records tool calls in an audit trail. Separate keys per agent are in progress. Consent grants, delegation chains, the tamper-evident log, the stop control and memory labels are planned. Policy checking with li is research. Taktwerk plans to bundle these features for Mittelstand companies, with a mapping to the oversight and logging duties of the EU AI Act.

We have written this up as a draft position paper. It contains no benchmark results yet, because there is nothing honest to measure until a prototype exists.