Agentic SOC Architecture: Your AI Can’t Hunt What It Can’t See

At 02:14 an agent notices a service principal reading mailboxes it has never touched before. It writes a hypothesis. Then it stops. Every read path it needs sits behind a credential it does not hold, and no amount of reasoning gets it further. Agentic SOC architecture fails here, well before the model does.

Agentic SOC architecture is the arrangement of read paths, identities and context-assembly logic that lets an autonomous agent reach security data across systems it does not own. Four parts: a route into each source, an identity that source will accept, a query layer that reconciles the schemas, and a context set assembled per hypothesis. Model quality is not one of the four.

Key takeaways about agentic SOC architecture

• Agent capability is bounded by read scope rather than model quality. An agent that reaches six of your nine security data stores can investigate only what those six reveal, however well it reasons.
• The architectural decision is where schema reconciliation happens: at ingestion time, in a pipeline someone maintains, or at query time, against the rate limits and retention windows the source vendor sets.
• Retention is the constraint that decides which hypotheses are answerable at all. Entra ID keeps sign-ins 30 days on a premium license, seven on Free; Okta returns nothing past 90. Neither answers a question about last spring.
• Any agentic AI SOC platform should report the sources it could not reach on a given hunt, because a clean result assembled from a partial read is unfinished work rather than an answer.

Your AI Agent Can't Reason Over Security Data It Can't Reach

Give an agent a detective's job and half a detective's badge. It walks the lobby, the mail room and two floors of offices. The records room is locked and the basement belongs to a different tenant. It still writes you a confident report about the lobby.

Take the service principal from the opening. The hypothesis is specific: an identity with mail scope changed behavior after eleven months of reading nothing. Three read paths would test it. The agent holds none.

• The sign-in records. The evidence lives in an Entra tenant the agent holds no credential for. Cost to fix: an app registration, an AuditLog.Read.All grant, a change-advisory slot.
• The mailbox audit trail sits in a SaaS admin console owned by IT. Cost to fix: a conversation about who owns the credential, which engineering cannot close alone.
• **The warehouse copy reads fine. **It landed nineteen hours ago, so it cannot answer a question about this morning when you need the answer. An honest agent also names what looks identical: an archiving service principal granted mail scope during an onboarding six months ago, dormant until its first scheduled run. Same access pattern, same burst shape, nothing to investigate.

IBM's Institute for Business Value and Palo Alto Networks surveyed 1,000 security executives across 21 industries and 18 countries and published the count in January 2025: the average organization runs 83 security solutions from 29 vendors. Take the number and leave the recommendation. Eighty-three products can mean dozens of access decisions across 29 vendor relationships, many owned outside the SOC.

The limit on an agent is not how well it reasons. It is how far its credentials reach.

Why Centralizing Every Security Signal Creates Another Bottleneck

The obvious response is to move everything into one store first. For an agent, that case is strong.

One schema means one query language instead of six. Latency becomes predictable, so a hunt plan can be costed in advance. A source going down no longer takes a read path with it. Access control and audit happen in one place, which matters when the thing doing the reading is not a person. Genuine advantages, none of them marketing.

The bottleneck arrives as a queue. Every new source is a parser, a field mapping, a backfill and a place in someone's sprint, so the agent's reach grows at the rate the pipeline team absorbs work. Sources with existing connectors get onboarded. The ones left outside are frequently the interesting ones: a regional identity provider, a finance SaaS application, a factory network's collector.

This isn't an argument about correctness. It's an argument about coverage.

Federation makes the opposite trade. It reduces storage and ingestion costs but picks up schema-reconciliation and latency costs, paid per query instead of once at build time. Three situations make that trade the wrong one:

• Joins across sources at interactive speed. Reconciling four schemas per question is slower than reconciling them once, and past a certain query volume that difference is the whole experience.
• The answer must survive the source. To investigate an identity provider during that provider's outage, the data has to be elsewhere already.
• The retention window is shorter than the question. No query reaches data the vendor deleted. Where those constraints do not apply, querying data where it lives keeps reconciliation per-question and reversible, rather than frozen into a pipeline you re-run to change.

The Context an Agentic SOC Needs Across the Security Stack

There is no widely adopted agentic SOC architecture diagram yet. Here is the one worth drawing: a table, not boxes and arrows between products.

The honest part of this picture is the part a diagram never shows.

Rate limits set how wide a hunt can be. Five requests per 10 seconds against Entra ID sign-ins may suit a focused investigation but can constrain a broad tenant sweep, which is why Microsoft recommends filtering on createdDateTime and iterating through shorter timespans. Permission boundaries often follow org charts rather than data, so reaching the SaaS audit trail may require a person’s approval before it requires an API.

Identity does not reconcile either. The same human is a UPN in one system, a principal ID in another, an email address in a third, and something has to hold that mapping. And some questions cannot be answered at query time at all: compare this quarter's service-principal behavior against the same quarter last year and no federated read reaches it, because the source deleted it nine months ago. That one needs a copy.

How Agents Turn Threat Intelligence Into Hunt Decisions

An advisory arrives describing OAuth consent abuse followed by mailbox rule creation. A human reads it and thinks about attacker behavior. An agent thinks about behavior and routes in the same pass, because the second decides whether the first is testable.

Three questions run in sequence:

• Which sources hold evidence of this behavior? Consent grants land in the identity provider's audit log. Rule creation lands in the application's audit trail. The sign-in context tying them together lands somewhere else again.
• Can I read all three? Two out of three is a hypothesis with a hole in it, and the hole sits exactly where the attacker's step is.
• **Does retention cover the window the advisory describes? **Advisories published today often describe activity from months ago. Against 30-day retention an agent can answer “is this happening now,” but not “did this happen months ago?” Intelligence about a campaign therefore carries a usable lifespan set by the shortest retention window among the sources needed to test it. An agent should name the advisories it can no longer test rather than reporting clean.

A consent grant to a third-party application followed by rule creation is also the signature of a mail-archiving tool IT deployed on a Tuesday. What separates them is who consented and whether a change record exists, which is a fourth source and often the one nobody exposed.

This is a read-path problem rather than a conversion problem. Turning intelligence into deployed detection logic is separate work, and an agent filling intelligence gaps across disconnected sources is separate again.

How Mars Security Enables Agents to Hunt Across Existing Telemetry

The method is query-in-place. Rather than moving telemetry into a new store, Mars Security queries it where it already sits, across SIEM, EDR, identity providers, cloud telemetry, Snowflake and Databricks, without requiring a separate normalization pipeline.

That approach has costs, and they are the ones described above. A hunt that waits for every source is as slow as its slowest one. A source that is down is a source the agent cannot read, and the answer has to say so. Every read path needs a scoped credential, which is permissions work per source and never zero. And where a question needs history the source no longer holds, a copy is still the right answer.

From Autonomous Hunts to Better Detection Coverage

A hunt produces two useful things: a finding, or a trustworthy negative. The negative is worth having only if you know which sources answered, which timed out and which were never reachable.

Make that accounting an output. Per hunt, record the sources queried, the sources skipped, the reason for each skip and the window actually covered. Rate-limited, unreachable and empty are three different results, and a system that renders them identically teaches a team its environment is clean.

Effective detection coverage follows read scope. A team cannot validate or run a detection for behavior it has no route to observe, so a coverage map built without a read map can overstate itself. Lay your ATT&CK coverage view next to your read-path inventory. Where a technique reads as covered but the telemetry sits in a source the agent cannot reach, closing the gap is a permissions ticket rather than a detection-engineering project.

Building an Agentic SOC Without Another Data Silo

Order matters. These are the decisions, in the sequence that stops the fifth one from being made for you.

• Decide where reconciliation happens, source by source. A high-volume endpoint source and a low-volume SaaS audit trail deserve different answers.
• Give the agent its own identity in every source. Scoped to read, distinct per source, never a borrowed analyst account. It should appear in the audit log as itself.
• Budget the rate limits before designing the query plan. Five requests per 10 seconds is an architectural fact, and it decides what a hunt can cover.
• Set a retention floor per class of hypothesis. Name the questions you intend to ask, then check whether any source still holds the data to answer them.
• Copy only what the floor forces, and write down the question that forced it. A copy with a named reason is an architecture. A copy without one is a data lake with better manners.
• Treat unreachable sources as a reportable output, reviewed monthly, owned by a person. Agentic SOC solutions that skip step one rebuild the thing they replaced, one connector at a time, and the second data store is always harder to retire than the first.

Frequently Asked Questions About Agentic SOC Architecture

**Is there a standard agentic SOC architecture diagram to work from? **

There is no widely adopted reference architecture yet, and vendor diagrams tend to put their own product in the middle. Draw a read map instead: every data store you hold, the identity the agent uses against it, its retention window, and its rate limit.

What does an agentic AI SOC platform need beyond access to a good model?

Credentials it can present to each source, a query layer that reconciles differing schemas and time semantics, retention it can reason about, and a memory of what it already checked. Model quality improves conclusions drawn from available data without extending reach.

How do you go about validating agentic SOC workflows before trusting them?

Replay a closed investigation you already understand, then check which sources the agent queried rather than only whether it matched your conclusion. An agent that lands the right answer while silently missing two sources got lucky, and luck does not repeat.

Do agentic SOC solutions require replacing your SIEM?

Not architecturally. An agent needs read access to the SIEM like any other source, and the SIEM stays useful for data that belongs in one place. Whether it remains your primary detection platform is a separate decision with separate economics.

When is copying data into a central store the right call?

When the question outlives the source's retention, when an answer must survive the source being unavailable, or when cross-source joins run often enough that per-query reconciliation dominates cost. Short list, and each entry deserves an argument.

Stop grading your agent on the quality of its conclusions. Start grading it on the doors it can open, because the second number caps the first and only one of the two shows up in a demo. A detective with half a badge writes a confident report about the half of the building they were let into. Give the agent the rest of the building. Until you do, agents hunting across existing telemetry remain an architecture diagram rather than a capability.