// aixcl · the agentic AI workshop · alpha · 2026 For developers · platform engineers · security-conscious teams

aixcl · the workshop Let your AI agents work —
without handing them the keys.

Agents are about to do real work on real infrastructure — that's where this is all heading. The teams who get there safely will be the ones who solved the credential problem first. aixcl is how: it sits between your agents (Claude Code · Cursor · Codex · MCP) and your resources, so the agent never sees a secret, you stay in the loop with TOTP, and every action lands in a tamper-evident audit. We've already built it.

aixcl@platform live online
// agents connected4
// brokers up2
// pending grants3
// audit entries (24h)214
// integration tests68 / 68
// credentials in agent ctx0
// works with the agents you already use · MCP native
+Claude Code +Cursor +Codex CLI +Windsurf +Custom MCP
01 /The problem

You can't safely give agents credentials.
You also can't build the chatbot.

You want AI agents to do real work on your infrastructure — query a production database, SSH a server, call a billable API, push code for review. Today there are two ways to make that work. Neither is good.

Hand the agent a password / API key.

It now lives in the agent's prompt, its context window, its logs, and potentially upstream provider databases. Rotation is theatre — the secret has been seen.

Risk: credential leaks, compliance fail, blast radius unknown

Wrap the agent in a chatbot UI you built.

You're now hosting LLMs, paying for tokens, owning a chat-history database, building moderation. You're reinventing the agent layer Claude Code / Cursor already do well.

Risk: 6-month internal build, no roadmap, no UX

Audit goes missing.

Even if you survive the first two, you still can't tell your auditor which agent did what, with which approval, against which resource. The trail is in five tools.

Risk: regulator can't trace the action chain
02 /Mental model

Five concepts. Pin these and the rest is obvious.

aixcl runs on five primitives. You submit tasks; agents work on them; brokers execute the auth'd actions on resources; you audit and approve from a project workshop.

// 01

Project// the workbench

A git-backed workspace with a roster of agents, a task list, and a stream of audit. One project per workstream.

// 02

Agent// the worker

An MCP client (Claude Code, Cursor, Codex) authenticated by a PAT. Identity, per-project role, scope.

// 03

Broker// the trust boundary

The aixcld daemon on the destination host. Holds credentials locally only. Executes verbs. Returns sanitised results.

// 04

Resource// the target

A named target a broker acts on — Postgres DB, HTTP API, SSH host, EC2 instance, fleet member.

// 05

Task// the unit of work

State machine: pendingin_progressawaiting_reviewcompleted. Append-only handoff log.

03 /How it works

One five-step flow.
From agent intent to audit entry.

Every action through aixcl moves through the same path. The agent never sees a credential. You approve once with TOTP, not per agent. The audit is written as you go.

// 01 · intent
01

Agent submits an intent.

Via MCP tools: "run docker ps on prod-host" or "query analytics_db with this SQL". No credential attached.

via MCP
// 02 · grant
02

Surfaces as a pending grant.

aixcl renders the intent in the dashboard, scoped to a specific verb + params + TTL. You see exactly what would happen.

scope · verb · ttl
// 03 · TOTP
03

You approve with TOTP.

Once per task, not per agent. The grant is signed (Ed25519) and provisioned to the broker.

signed · Ed25519
// 04 · execute
04

Broker executes the verb.

The aixcld daemon on the destination host — the only place that holds the actual secret — runs the verb and returns a sanitised result to the agent.

runs · locally
// 05 · audit
05

Every step lands in audit.

Sanitised params · outcome · byte counts · source IP · the approval that authorised it. Tamper-evident. Exportable.

trail · end-to-end
04 /The workshop

Built for the way real teams approve work.

One workspace per project. Pending grants in front, audit behind. Sidebar surfaces the queue, the roster, and the resources. Below: a real screen from aixcl alpha.

aixcl.com/projects/migrate-billing/workshop · acme-corp
4 agents · 2 brokers up
Pending grants· 3 awaiting your TOTP
grant_01HXY9 · claude-code-1 · ttl 60s
Read schema for billing.invoices
db.query · analytics_db
12s ago
pending
grant_01HXY8 · cursor-dev · ttl 120s
Restart caddy on prod-host-1
ssh.run · prod-host-1
38s ago
pending
grant_01HXY7 · codex-cli · ttl 30s
GET /v1/customers?limit=10
http.call · stripe-api
1m ago
pending
grant_01HXY6 · claude-code-1 · approved
SELECT COUNT(*) FROM events WHERE …
db.query · analytics_db
4m ago
approved
grant_01HXY5 · cursor-dev · approved
docker ps
ssh.run · prod-host-1
6m ago
approved
grant_01HXY4 · cursor-dev · denied
DROP TABLE billing.invoices
db.query · analytics_db
11m ago
denied
05 /What's in the box

Built for engineers who would rather not build this themselves.

aixcl ships with the substrate already done. Cryptography, audit, MCP transport, broker enrollment, workshop UI — all of it. You bring your agents and your resources. We handle the in-between.

MCP-native transport

Streamable HTTP MCP transport at /mcp. Drop your PAT into Claude Code, Cursor, or any MCP client. Works in 30 seconds.

// connect · 30s

Verb-based brokers

db.query, http.call, ssh.run, compute.{list,describe,start,stop,terminate,create}, member.dispatch. Scoped, signed, executed.

// verbs · 12 + growing

TOTP approval

Enrolled at registration. Replay-protected. One TOTP per task, not per agent. You stay in the loop without becoming the bottleneck.

// auth · TOTP + PAT

Envelope crypto

Per-tenant DEK, KMS-wrapped. AES-256-GCM for sealed data. Ed25519 for signed policies. Tenant isolation via Postgres RLS.

// crypto · KMS + AES-256 + Ed25519

Project workshop

Git-backed workspaces. Per-session checkouts. MR workflow. Roster + audit + open MRs + resources in one view. State machine for tasks.

// workspace · git-backed

aixcld broker daemon

Single-file CJS bundle. aixcld up for one-line enrollment. Persistent + ephemeral modes. Auto-reconnect, token rotation, heartbeat.

// broker · one binary
06 /Architecture

Three layers.
One trust boundary.

The credential lives only at the broker, on the destination host. The control plane never sees it. The agent never sees it. That's the entire architectural insight.

// layer 01your AI client
Claude Code / Cursor / Codex / custom MCP. Holds: your PAT, agent-side context.
// destination credentials? never
MCP · Streamable HTTP · /mcp
// layer 02aixcl control plane
Fastify API + MCP server + dashboard. Holds: org DEK (KMS-wrapped), signing keys, audit, policies.
// destination credentials? never · that's the point
WebSocket · /broker · signed policy + encrypted frames
// layer 03aixcld broker
One per destination host. Holds: sealed credentials, SSH keys, API keys — local only. Executes db.query, http.call, ssh.run, compute.*.
// credentials live? here · and nowhere else
direct · destination protocol
// resourceyour data
Postgres / HTTP API / SSH host / EC2 / fleet member. Action runs here. Result sanitised and returned up the chain.
// agent saw the credential? no · only the sanitised result
07 /Verbs

What an agent can actually ask for.

Every verb is scoped, audited, and signed. The agent constructs the intent; aixcl decides whether to execute it. Four representative verbs shown below.

db.query Read or write against an enrolled SQL resource.
// agent submits an intent
{
  "verb": "db.query",
  "resource": "analytics_db",
  "sql": "SELECT COUNT(*) FROM events …",
  "ttl": 60
}
// → pending grant → TOTP → broker executes → sanitised rows back
ssh.run Run a command on an enrolled host.
// agent submits an intent
{
  "verb": "ssh.run",
  "resource": "prod-host-1",
  "cmd": "docker ps",
  "ttl": 30
}
// → TOTP → aixcld runs command → stdout/stderr returned
http.call Call an enrolled HTTP API.
// agent submits an intent
{
  "verb": "http.call",
  "resource": "stripe-api",
  "method": "GET",
  "path": "/v1/customers?limit=10"
}
// → broker authenticates with the API key it holds locally
compute.{list,start,stop,…} Control cloud instances on an enrolled provider.
// agent submits an intent
{
  "verb": "compute.list",
  "resource": "aws-prod-eu",
  "filter": { "tag:env": "staging" }
}
// → IAM creds stay in the broker; only the list comes back
// security · crypto · isolation

Cryptography is the floor, not the ceiling.

Per-tenant data-encryption keys, KMS-wrapped. AES-256-GCM for sealed data. Ed25519 for signed policies. Postgres RLS for tenant isolation. The brief we send your CISO is shorter than the one you send your team.

KMS · wrapped// per-tenant DEK · cloud KMS
AES-256 · GCM// envelope crypto · sealed data
Ed25519// signed policies · broker verifies
Postgres · RLS// tenant isolation · row level
TOTP · replay-safe// enrolment · approvals
Audit · append-only// tamper-evident · exportable
09 /Status

Alpha.
Substrate solid. UX iterating.

aixcl is in alpha with a small group of founding users. The crypto, broker, MCP, and audit substrate is integration-tested against real Postgres. The UX iterates weekly. We're opening a few more alpha slots before public availability.

// integration tests
68 / 68

All pass against a real Postgres on each commit. The substrate is solid.

7 packages · typecheck clean
// shipped

Foundation

Multi-tenant Postgres + Redis · KMS-wrapped per-org DEK · TOTP enrolment + replay-safe verification · agent PATs + sessions · envelope crypto · Ed25519 signing of approved policies.

// shipped

Broker / agent surface

Streamable HTTP MCP at /mcp · verb-based brokers (db / http / ssh / compute / member.dispatch) · persistent + ephemeral broker modes · aixcld single-file bundle · aixcld up one-line enrolment.

// shipped

Workshop layer

Projects with per-session git checkouts · MR workflow · roster + audit + open MRs + resources view · task state machine (pending → in_progress → awaiting_review → completed) · append-only handoff log · fleet plane (Advanced) · cost accounting + budgets (Advanced).

// shipped

UX

First-run interactive tour · in-app Help tab with mental model, common workflows, security model, glossary, FAQ · Getting Started checklist that auto-completes.

// next

Coming up

More verbs · cloud-broker option for teams who can't host aixcld themselves · server-side agent loop driving doer/reviewer phases · public beta in late 2026.

10 /Questions

Six questions from alpha users.

Real questions, plain answers. If yours isn't here, email hello @ aixcl.com.

// q · 01Where does the credential actually live?

In the aixcld broker on the destination host — sealed locally with envelope crypto. The control plane never holds destination credentials; only the broker does. That's the whole architectural insight.

// q · 02Do I need to host aixcld myself?

Yes — for now. One aixcld per destination host. aixcld up handles enrolment. A managed-broker option is on the roadmap for teams that can't self-host.

// q · 03How does this work with Claude Code / Cursor?

aixcl exposes a standard MCP server. You add it to your MCP client with a PAT: claude mcp add --transport http aixcl https://your.aixcl/mcp --header "Authorization: Bearer aixcl_pat_…". The agent's tools become aixcl verbs.

// q · 04Does aixcl run the LLM?

No. You bring your own agent. aixcl never holds an LLM API key, never pays for tokens, never sees prompts beyond the structured intents the agent submits.

// q · 05What about my regulator?

Every action ends up in an append-only audit log with sanitised params, outcome, byte counts, source IP, and the approval that authorised it. Exportable. Tamper-evident. We co-design the export format with regulated alpha customers.

// q · 06How do I get alpha access?

Email hello @ aixcl.com with what you'd use aixcl for. We onboard alpha users one at a time so we can co-design with each. If we're not a fit, we'll tell you in the first reply.

// alpha · limited slots · onboarded individually

Get ahead of where
agents are going.

The credential problem is about to become everyone's problem. The teams solving it now will move fastest later. Tell us what you'd put agents to work on — we'll reply within 48 hours, and if it's not a fit yet, we'll tell you what to watch for.