Security teams are moving from experimenting with AI to deciding where AI should actually live in their operating model.
Some organizations are building agents internally. Security vendors are embedding agents into their products. Others are evaluating standalone platforms that can coordinate AI across the existing security stack.
The technology choice matters, but the architectural choice matters more. Where agents operate, how they share context, who controls their authority, and who owns the integration burden will determine whether AI becomes another layer of tooling or becomes part of how the security organization operates.
For CISOs and security leaders, that brings back a familiar enterprise question: Build, Buy, or Partner?
The answer will vary by organization. But the decision becomes clearer when you look beyond the individual AI agent and examine the architecture around it.
The Lesson from Enterprise Security Architecture
Security organizations have faced versions of this decision before.
SIEM platforms emerged as organizations decided whether to build their own log aggregation and correlation infrastructure or adopt a platform. SOAR introduced another layer of decision-making around whether to maintain custom scripts and workflows or use a platform to orchestrate them. More recently, cloud security and XDR have brought similar questions about integrated platforms versus individual tools.
The lesson is not that one approach always wins. It is that the layer an organization chooses to own has long-term consequences. Teams can end up maintaining parsers, integrations, and custom scripts long after the original problem they were built to solve has changed.
Agentic AI introduces another version of the same decision. Models and tools will continue to change, and organizations will build some capabilities while acquiring others. The question is where the AI operating platform belongs.
Build: When AI Infrastructure Becomes Your Responsibility
Building can make sense. Organizations with deep engineering resources, proprietary requirements, regulatory constraints, or strategic reasons to own their AI infrastructure may choose to develop capabilities internally.
But building an agent is only part of the problem.
A production AI workforce also requires:
- Agent orchestration and workflow management
- Integrations with the existing security environment
- Persistent context and information management
- Model selection and provider management
- Identity, permissions, and runtime controls
- Auditability and observability
- Testing, evaluation, and ongoing maintenance
A prototype can connect a model to an API and demonstrate useful work. A production system has to manage what happens before, during, and after that interaction.
That means the organization is not simply building an AI agent. It is taking responsibility for the infrastructure, governance, security, and operational model around that agent.
For some organizations, that is the right choice. The important question is whether AI infrastructure itself is something the organization wants to own and operate over the long term.
Buy: Look Beyond the AI Feature
Commercial software can reduce much of that engineering burden, but not every AI product solves the same problem.
Security vendors are increasingly embedding AI into their products. An endpoint platform can apply AI to endpoint telemetry. An identity platform can apply AI to authentication and access activity. A threat intelligence platform can apply AI to research and analysis.
Those capabilities can be useful within their respective domains. But enterprise security work rarely stays within one domain.
An investigation may begin with an endpoint alert, require identity context, pull in threat intelligence, examine cloud activity, and ultimately involve vulnerability or access-control decisions. When that happens, the architecture needs to coordinate work across systems rather than simply make one product smarter.
This creates an important distinction between buying an AI capability and buying an AI operating platform.
For the CISO, the questions become:
Where does context live? A good answer should explain how information persists across agents, workflows, and investigations rather than disappearing with an individual model session.
How are agents coordinated? A good answer should show how multiple agents work toward a common objective, including how context and handoffs are managed between them.
How is authority controlled? A good answer should define who can run procedures, what systems agents can access, and which actions require approval or other controls.
How does the platform integrate with the existing security environment? A good answer should avoid forcing the organization to rebuild its security stack around a new AI system.
Can it expand beyond the initial workflow? A good answer should make it possible to start with a focused use case and extend the same architecture across additional security workflows.
For the AI architect, there are additional questions around model selection, evaluation, data residency, non-human identities, and portability. Can the organization change model providers without rebuilding its workflows? Can it understand what an agent did and why? Where does the context persist, and who controls it?
The architectural distinction can be summed up simply:
Connecting a model to a tool gives it an action. It does not give the organization an operating model.
Partner: Extending Across the Security Environment
The third option is to partner with an organization that provides some or all of the capabilities required to put AI into production.
That partnership can take different forms. An MSSP or services provider can operate AI-enabled security workflows on behalf of customers. A systems integrator can help design and implement the architecture. A technology platform can provide the underlying infrastructure for coordinating AI across the security environment.
The value of a technology partner is not simply access to another AI capability. It should reduce the integration, governance, and operational burden of putting AI to work.
Security vendors are already introducing agents into their products. EDR platforms have endpoint context. Identity platforms have authentication and access context. Cloud platforms have resource and configuration context. Threat intelligence platforms have their own specialized information.
The challenge begins when the work crosses those boundaries.
The operating platform has to connect those capabilities while preserving context, coordinating the work, and enforcing the organization’s policies.
The Architecture Behind the Decision
Whether an organization builds, buys, or partners, the underlying architecture needs to address three things: Context, Coordination, and Control.
Context
Agents need access to the information required to perform their work, and that context needs to persist beyond an individual model interaction.
An agent investigating an alert may need information from previous investigations, related entities, organizational procedures, threat intelligence, and activity across multiple security systems.
That requires more than passing information into a model’s context window. The architecture needs a way to structure and persist information so agents can access the right context at the right time.
Coordination
Security work is rarely a single action performed by a single agent.
Different tasks require different expertise. One agent may understand the role of a security analyst, while another has specialized knowledge of an EDR, SIEM, identity platform, or threat intelligence system.
This is where Role Agents and SME Agents become useful. Role Agents understand the work a security professional needs to accomplish. SME Agents bring specialized knowledge of security tools and functions. An operating platform coordinates them around a common objective while preserving the context of the work.
Control
Autonomy without control is not an enterprise operating model.
Organizations need to establish who can run procedures, which systems agents can access, what actions they are authorized to take, and how their activity is recorded. Human oversight remains part of the operating model, particularly as organizations expand the scope and autonomy of their AI workforce.
As Astronomer’s CISO Josh Domagalski put it:
“With distributed agents, you can enforce guardrails and understand what each one is doing — that’s what makes Bricklayer different from every other AI tool we evaluated.”
That is fundamentally a control question. The organization needs visibility into what agents are doing and the ability to define and enforce the boundaries within which they operate.
The practical impact can be seen in a workflow such as phishing response. An AI workforce can triage the initial alert, investigate the sender and related indicators, consult threat intelligence, identify affected users, and prepare the recommended containment actions. The analyst remains in the loop for the decision that requires human judgment, such as approving account suspension or broader containment. The value comes from coordinating the work across those steps, not simply accelerating one step within one tool.
Where Bricklayer Fits
Bricklayer provides the AI operating platform for coordinating a governed security workforce across the existing security environment.
It does not require an organization to replace its security stack or standardize on a single security vendor. Instead, it provides the architecture for deploying and coordinating AI agents across existing tools and security workflows.
Context: Bricklayer’s Agent-Native Data Plane provides persistent, structured access to the information agents need outside of individual model contexts.
Coordination: Bricklayer uses the Role Agent and SME Agent architecture described above to coordinate work across alert triage, incident investigation, threat intelligence, vulnerability management, threat hunting, and other security workflows.
Control: Governance capabilities establish permissions, organizational boundaries, auditability, and the controls that determine what agents can do and how their work is recorded. Bricklayer’s platform supports policy enforcement, RBAC, and audit trails across agent activity.
The architecture also separates the AI workforce from any individual model provider. Organizations can make model choices based on factors such as performance, cost, speed, and compliance requirements without rebuilding the operating model around each change.
Portability should also be part of the decision. Organizations should ask what happens to their procedures, context, findings, and audit history if they change AI platforms. The answer should be specific, documented, and address both data ownership and the practical mechanisms available for retaining or exporting information. For example, Bricklayer supports export of platform audit logs for independent retention and compliance review. Buyers should ask the same level of specificity about the other information their AI workforce creates and relies on.
The Decision That Matters
Most enterprises will ultimately use some combination of build, buy, and partners.
The more important decision is where the AI operating platform belongs.
That platform needs to provide persistent context, coordinated execution, and meaningful control. It also needs to give the organization flexibility as models, agents, and security technologies continue to evolve.
For the CISO, the objective is to increase security capacity without giving up governance or human control. For the SOC leader, it is about getting more work through the team. For the AI architect, it is about building an architecture that can evolve without having to rebuild the foundation every time the technology changes.
That is the architectural decision worth making now.
Explore the Bricklayer Approach
See how Bricklayer’s coordinated AI workforce works across real security workflows, or explore the Bricklayer Partner Program for organizations helping customers implement and operate AI-enabled security.
