Multi-agent security operations: LimaCharlie’s architecture, built for auditability

Most multi-agent security deployments fail in production not because the agents can't act, but because there's no shared context layer between them. When something goes wrong, the audit trail doesn't exist. In LimaCharlie, solving that problem is architectural, and the solution starts with how individual agents are defined.

LimaCharlie Co-founder Christopher Luft offered a brief overview of the architecture in his video, LimaCharlie is the most secure way to run AI security agents:

Understandable, configurable agents

In LimaCharlie, an agent is a record, not a running process. You describe the agent: which model it uses, its instructions, which tools it can reach, what triggers it, and its operational limitations. The platform handles execution from there.

Because agent definitions are plain text, they are version-controllable, reviewable, and portable across tenants. Changing how an agent behaves means editing a prompt and saving it, with the same change control workflow you would apply to a detection rule. The configuration exposes no proprietary wrapper or hidden execution layer; every behavior can be read and reasoned about by a human operator.

Each agent also carries a model selection, Opus, Sonnet, or Haiku, chosen based on the task. For most triage and response work, Sonnet hits a reasonable balance between reasoning depth and cost. Opus is worth the additional overhead for tasks that require correlating across multiple detections or generating a structured incident summary. The selection is explicit, visible in the configuration, and easy to change.

Two-layer access control

Tool access in LimaCharlie uses two stacked layers. The tool allow list on the agent defines which MCP tools the model can reach for. The API key the agent authenticates with determines which platform actions are actually permitted. Both layers are visible in the configuration.

This means you can reason precisely about what any given agent can and cannot do. An investigator agent can query telemetry and read cases. A responder agent can isolate an endpoint. A reporter agent can write case notes. Each has a scoped identity and set of permissions. The system does not rely on a monolithic set of credentials shared across all agents.

Guardrails in LimaCharlie also operate at the agent level. A max budget setting limits spending on model API calls, and other settings prevent an agent from running indefinitely if it gets stuck in a loop. 

Both apply independently of how much you trust the agent. A misconfigured loop on an otherwise well-behaved agent can accumulate cost quickly, and these settings exist to catch that.

Why LimaCharlie multi-agent systems stay coherent

A multi-agent system is only as trustworthy as its coordination mechanism. LimaCharlie uses the case record as the shared context layer between agents, which in turn affects how the system behaves.

Agents communicate through the case, not through ad hoc memory or direct message passing. When a triage agent opens a case and records its findings, the investigator that picks up the work reads from that case. When the investigator completes its analysis, it writes back to the case before flagging the responder. Every handoff leaves a trace. Every piece of reasoning is attached to a record that a human analyst can read at any time.

This is also what makes human-in-the-loop oversight achievable in a live production environment. Because everything flows through the case, an analyst can step in, review what the agents have done, approve or override a pending action, and let the run continue. 

Human guidance happens without disrupting the workflow. The agent does not need to be paused or restarted. The case is the interface between the agent team and the human operator.

The alternative, agents maintaining independent memory and passing state through ad hoc channels, produces systems that are hard to audit and difficult to intervene in. When something goes wrong, tracing the cause requires reconstructing state across multiple execution contexts. In LimaCharlie, the audit trail is the case record, and it is always current.

Triage, investigation, response: a team of AI specialists

A multi-agent team in LimaCharlie follows a division of labor that maps closely to how mature SOC teams are structured. The triage agent receives the triggering event, classifies it, and determines what the situation requires. It functions like a tier-one analyst who both evaluates the alert and routes the work. If deeper investigation is needed, the investigator takes the case. If containment is warranted, the responder agent acts. If findings need to be communicated, the reporter agent writes them up.

Each specialist has a narrow, well-defined job. The investigator gathers context: process trees, network connections, related events, historical activity on the host. The responder takes containment actions, scoped to the permissions its API key permits. The reporter produces output in a format a human analyst can consume.

Overloading an agent with too many responsibilities degrades the quality of its reasoning. A specialist with a narrow prompt and a focused set of tools performs more reliably than a generalist asked to handle the full scope of SOC work. The composable model also makes the system easier to modify. Changing how investigation works means editing one agent definition, not restructuring a monolithic system.

Building agentic teams without hand-coding everything

LimaCharlie includes an AI terminal that can help define agents and multi-agent systems interactively. You describe what you need the team to do and it produces agent definitions, suggests tool allow lists, and proposes the API key permissions to pair with each agent. 

The output is a starting point, not a finished product. A human operator reviews and adjusts before deployment, but the scaffolding cuts the time between concept and a working configuration.

For teams building a multi-agent system from scratch, this is a significant reduction in upfront work. The platform handles execution. The AI terminal handles scaffolding. The operator defines intent and reviews output.

What this means for SOCs and MSSPs

The architectural properties described here have practical implications for any team running agentic SecOps at scale.

For SOC teams, they mean you can build an agent team that matches your operations exactly. You can modify it as your environment changes, and maintain a readable audit trail of everything the agents do. There is no vendor roadmap to wait on and no black boxes hiding critical operations from view.

For MSSPs managing multiple tenants, they mean agents can be scoped per tenant and per workflow, with independent permissions and independent audit records for each customer environment. The same agent definitions are portable across tenants. A prompt update in one place applies consistently across every tenant.

Having the case record act as a coordination layer directly supports the kind of customer-facing reporting that MSSPs need. When a multi-agent run completes, the case contains a complete record: who looked at what, what they found, and what actions were taken and why. Turning that into a customer report is an easy task.

Next steps

To see the platform and try it yourself:

Sign up for a free account

Read the docs

Explore the lc-ai GitHub repo

Book a demo