API-first is why AI works in some SOCs and stalls in others

AI is making significant leaps in cybersecurity, but only where the underlying architecture allows it. On platforms built around closed, vendor-defined workflows, AI runs into the same walls that human operators do: limited access, opaque data paths, and capabilities gated behind product release cycles. 

LimaCharlie was built API-first, which makes it a natural fit for agentic AI operations. Every function available through the web interface is also available via API: detection and response, telemetry queries, case management, endpoint actions, tenant administration. 

The web portal is a convenience layer on top of the API, not the other way around. There are no capabilities reserved for human operators through proprietary UI features, no functions gated behind vendor-controlled access points, and no part of the platform that AI cannot reach through the same paths as humans. 

With access to an open API platform, agentic operations naturally evolve across three distinct milestones. Each step builds upon the last. The sequence only works because of the architectural decisions that grant AI full platform access while imposing necessary guardrails. The diagram below shows what that difference looks like in practice.

LimaCharlie’s API-first approach to building a security stack removes the obstacles that traditionally hinder AI operations in SecOps.

Milestone 1: The open API foundation

The most important prerequisite for AI in a SOC comes down to infrastructure. Does the platform treat all operators, human and machine, equally?

An AI agent operating on LimaCharlie has the same access as a human analyst. It can query telemetry, write and test detection rules, trigger response actions, open and update cases, and manage infrastructure. The distinction between a human operator and an AI agent comes down to a single variable: the permissions policy assigned to that agent.

By ensuring all operators perform tasks the same way, at the infrastructure level, we solve one of the toughest challenges with putting AI into production: governance. AI is probabilistic by nature and therefore unreliable at governing itself. Enforcement has to happen externally, and on a layer the AI cannot modify.

LimaCharlie's platform enforces standardized processes across operators with infrastructure-level access controls. The same role-based access control (RBAC) model that applies to human analysts applies to AI agents. 

You can grant an agent investigation authority without remediation rights. You can scope it to specific tenants. Regardless of permissions or operator identity, security operations are performed in specific, non-variable ways across the environment.  

Because LimaCharlie’s guardrails are structural rather than behavioral, AI variability is constrained at the permission layer and cannot affect operations.

Milestone 2: Agentic operators

With the right foundation in place, AI agents can take on specific, defined roles in a SOC, the same way people do. Guided by the expertise of your team, these agents can be configured to perform critical tasks and provide continuous coverage across SOC operations.

LimaCharlie's public AI agent repository (github.com/refractionPOINT/lc-ai) contains a working set of standalone agents deployed as infrastructure-as-code. Each agent is defined by a prompt, a model, a permissions policy, and a set of available tools. 

The definitions are plain text, fully visible, forkable, and editable. Changing how an agent behaves is as simple as editing the prompt. Understanding why an agent took a specific action means reading the session log. Building a new agent takes minutes. See how the repository is structured: github.com/refractionPOINT/lc-ai. Each agent in the repository is defined in under 50 lines of plain text.

Each agent handles a specific security function: investigation workflows, threat evaluation, detection engineering, IOC hunting. They are not general-purpose assistants waiting for a human to formulate a query. They are specialized operators assigned to a task, running continuously, with access to the same platform capabilities a senior analyst would use.

Agentic operators streamline security workloads, augment your team’s capabilities, and provide continuous coverage.

This changes what analysts spend their time on. Junior analysts work alongside agents that carry institutional knowledge, closing the experience gap that typically takes years to build. Senior analysts move off repetitive triage and onto the work that actually requires their judgment. The agents handle the volume. The humans handle the decisions that matter.

The operational consequence is significant for teams managing multiple customer environments. Agents do not get tired, do not have context-switching overhead, and can run in parallel across hundreds of tenants simultaneously. The work that previously consumed the time of several dedicated analysts becomes a configuration decision.

Milestone 3: AI as forward deployed engineers

The third milestone is the one most organizations haven't reached yet, and represents the most significant shift in how AI fits into security operations.

The forward deployed engineer (FDE) model has a well-established precedent in enterprise software: instead of handing a customer a product and documentation, you embed an engineer with deep platform knowledge on-site, give them direct accountability for outcomes, and have them build whatever is needed to deliver results. The model works because expertise and ownership sit in the same role.

LimaCharlie's FDE, available through Grid, applies the same concept with an AI agent in the embedded role. You describe the security outcome you need. The diagram below shows what this looks like for a single use case: monitoring privileged accounts for anomalies.

It does not perform the security work directly; it manages the agents that do, checks in regularly, and communicates findings back to human analysts through LimaCharlie's case management system.

Example: An FDE is created to monitor privileged accounts for anomalies

The FDE model is where the previous two milestones become load-bearing. An FDE without real platform access cannot build agents that do real work. Agents without infrastructure-level governance cannot be trusted to operate autonomously. 

The open API foundation and the agentic operator layer are both prerequisites for a functioning FDE, which is why this progression moves in the order it does.

Why the order matters

Most platforms that have struggled to deploy AI effectively tried to add it as a feature on top of existing architecture. The AI got the access the vendor decided to expose, governed by policies the AI was expected to follow, and the results were predictably constrained. The platforms where AI is producing real operational value built access and governance into the foundation before the AI conversation started. The AI inherited an environment it could naturally work in. 

That is the difference between AI that advises and AI that operates, and it explains most of the gap between the SOCs that are advancing and the ones that are stalling.

Run AI operators across the stack you already have: https://limacharlie.io/grid

See how the agent repository is structured and fork it for your own environment: https://github.com/refractionPOINT/lc-ai/tree/master