Loading...
Loading...
An AI SOC Agent needs the tribal knowledge your logs never record: what each asset is worth, who owns each identity, how your team runs its processes, and which decisions your team already made. Without it, work repeats. In Devo's 2025 survey, 84% of organizations said their analysts unknowingly investigate the same incidents several times a month.
Your logs record what happened on every host. They've never recorded why most of it was fine. That reason lives in your senior analysts' heads, and no SIEM query will ever return it.
At 02:14 UTC on a Tuesday, your EDR flags encoded PowerShell on BUILD-07. A new analyst, human or AI, starts pulling process trees and network connections. Your most senior analyst would close it in thirty seconds, because the svc-backup account runs that exact script on every BUILD host at 02:00 UTC.
Nothing in the alert says so.
An AI SOC Agent starts its first day in that gap, with a capable model and no knowledge of the company.
In security operations, tribal knowledge is the undocumented context senior analysts carry in their heads: what each asset is worth, who owns each account, how the team handles each alert type, and what it decided last time. An AI SOC Agent needs all four to reach your best analyst's verdict, because telemetry carries none of them.
Your SIEM fires because something happened, and it can't tell you whether that something matters. Devo's 2025 survey of 200 US security managers ties those repeat investigations to high alert volume, frequent false positives, and insufficient context for each alert. Context is also what clears alerts. Arctic Wolf's 2025 report found 71% of alerts across 10,000+ customer networks were cleared as expected or benign by applying customer context and threat intelligence.
More data doesn't fix it. A security data lake can keep every event for a year, and none of those events says why the svc-backup script is fine. Anthropic's engineering team described the model-side problem in 2025 as context rot, where recall declines as the context window fills, so good context engineering means finding "the smallest possible set of high-signal tokens." Tribal knowledge is that set.
Simbian's AI SOC Agent reads this tribal knowledge at run time from the Context Lake™, organized in four layers: assets, identities, processes, and decisions.
| Tribal knowledge layer | What the layer adds to an alert | Example |
|---|---|---|
| Assets | What the system is worth and what it touches | A nightly-rebuilt QA VM vs. the payment database |
| Identities | Who owns the account, what is normal for them, who to call | svc-deploy is your CI service account |
| Processes | The steps your team runs, and when actions freeze | Quarter-end change windows at a bank |
| Decisions | What you concluded last time, and why | An InfoSec user's blocked PCI test-data upload is benign |
The same alert means something different on every asset. Fifty failed admin logins on a QA test VM that is rebuilt every night is housekeeping. The same fifty on the server that settles card payments is the most important thing in your queue.
NIST CSF 2.0 has asked since 2024 that assets be prioritized by criticality (ID.AM-05). Most teams have a CMDB, and many SIEMs already run asset and identity lookups. What those lookups lack is the reason: why a host matters this week, and what your team decided the last time it alerted.
Criticality also moves with exposure. When Simbian's AI Pentest Agent proves a path into a host, that finding lands in the Context Lake the AI SOC Agent reads. The SOC side then checks that your detections cover that path and investigates any alert that trips it, so the host's business value stops being the only input.
Identity context tells an investigation who is behind a username, what is normal for that person or service account, and who can confirm it. Arctic Wolf's 2025 data shows why it matters. In its SOC, 72% of the direct interventions made to block a threat involved identity actions, such as disabling hacked accounts or resetting passwords.
A contractor's VPN session is fine right up until the day the contract ends.
Investigations also stall on ownership as often as on evidence. An owner field that reads "IT Operations" names a department nobody can page at 2 a.m. An Agent that knows the real owner can ask them directly in Slack or Teams.
The process layer is where tribal knowledge is most organized and least used. Your SOC runbooks live in Confluence, a SharePoint folder, or a PDF attached to a ticket in 2023. The process layer turns those SOPs and escalation procedures into steps the Agents follow, alert type by alert type.
It is also where two companies with identical tools should behave differently. Take one alert, PII leaving for an unsanctioned cloud storage bucket, and three right answers:
All three answers live in somebody's runbook.
Decisions are the layer most teams lose. Every verdict carries a reason, and the reason usually sits in a ticket comment nobody will read again. Past verdicts and corrections are institutional knowledge, and they should outlive the analyst who made them.
One real alert from a large enterprise customer shows how this layer works. Endpoint DLP caught a user uploading PCI DSS test data, blocked it, and raised a high-severity alert anyway. The investigation found that nothing left the building, the user sat on the InfoSec team, and the file was labeled test data. Then it found a note the customer had uploaded earlier, saying that with no impact the alert is a false positive. Simbian's AI SOC Agent closed the case and still flagged that an attacker could use "test data" as a decoy.
Simbian CPO Sumedh Barde explains where notes like that come from: "Chances are somebody uploaded this document here because the first time around we got it wrong." Every correction your team makes is tribal knowledge with a reason attached, and the next analyst, or the next Agent, needs that reason.
Tribal knowledge needs an expiry date because a fact that was true last quarter can quietly blind you this quarter. An "expected behavior" entry with no end date is an exception that never closes, and every alert it touches gets discounted long after the reason for it is gone.
We have seen it in the field. A red-team exercise gets added as expected activity on a set of hosts. The exercise ends, the context stays, and investigations keep discounting real alerts on those hosts. Nobody decided to create a blind spot. Nobody decided to remove one either.
The more context you give an Agent, ours included, the more places a stale fact can hide. That cuts against us, and it's the price of memory.
So every fact should be time-scoped. One you add for a quarter can expire instead of steering next year's verdicts. Uploaded reference sheets carry a date stamp too, so owner-list records older than 90 days can be flagged before an Agent trusts them.
Memory poisoning is the most serious security risk of AI Agent memory: one false "this is normal" entry, written by an attacker or by mistake, suppresses real alerts until someone removes it. Microsoft's 2026 guidance on AI Agent memory safety warns that "Memory is candidate context, not authoritative truth." Expiry, scope, and review keep a wrong entry from becoming permanent.
Nothing reaches Simbian's AI Agents without a human's say-so, and every change to their memory goes through one queue. Each piece of tribal knowledge entering the Context Lake arrives as a tracked request showing who asked and a before-and-after diff of what changed. Anything the AI SOC Agent proposes always waits for human approval, as does anything submitted without write permission.
Three writers share that queue: a person submitting a fact, an analyst correcting a verdict, and the Agent proposing a change of its own. Before writing anything, Simbian checks existing context and updates it in place, so knowledge doesn't fragment into duplicates or contradict itself. A conflicted request is never applied.
The Agent's own requests show self-improving defense at work. At another large enterprise customer, the AI SOC Agent noticed it hunted across a whole host every time a signed admin tool tripped a process-hollowing alert. It wrote a narrower investigation for that alert type, ending on a line that says when to stop, and filed the change for approval.
A person approved it.
Every matching alert at that customer since has used that investigation, and verdict quality held.
Response works the same way. Customers' own analysts approve 95% of the responses Simbian proposes. Their call, not ours.
Write tribal knowledge in four parts: the fact, its scope (hosts, accounts, or ranges), the reason, and an expiry date if it is temporary. Scope and reason are what tell an Agent when the exception doesn't apply, so it keeps investigating the cases you never meant to excuse.
| Vague tribal knowledge entry | Scoped entry an AI SOC Agent can use |
|---|---|
| "Ignore PowerShell alerts." | "svc-backup on BUILD-* hosts runs encoded PowerShell nightly at 02:00 UTC. Expected CI behavior." |
| "10.20.0.0/16 is fine." | "Port scans from 10.20.0.0/16 are our Qualys scanner subnet. Other alert types from this range are still investigated." |
| "Contractors have access." | "Vendor X contractors (ctr-x-*) have approved VPN access until March 31, 2027. Flag any access after that date." |
Look at what the scoped PowerShell entry does. If the script runs at 3 a.m. instead of 2, the Agent investigates fully. If the time matches but your CI system didn't launch it, the Agent investigates fully. The blanket version removes protection everywhere.
Including the case you meant to keep.
Three habits keep entries like these healthy:
Most teams fight noise with exclusions added one at a time, one IP or one hash per ticket, and each one silences a symptom without recording why the noise happens. A generalized entry records the pattern behind them. The scanner row in the table is one: a single entry covers every scan from that subnet, however many hosts it touches, and every other alert type from the range is still investigated in full.
Simbian's AI SOC Agent starts reading your tickets and runbooks in the first days of deployment, and every action starts gated until you decide which ones stop being gated.
Q: What is tribal knowledge? Tribal knowledge is the undocumented know-how a team keeps in its heads rather than its systems: why a process runs the way it does, which exceptions are safe, and who to ask. In a SOC, it is the context that lets a senior analyst clear an alert in thirty seconds, and it leaves when that analyst does.
Q: What does an AI SOC Agent need to know about my environment? An AI SOC Agent needs four layers of tribal knowledge that telemetry doesn't carry: what each asset is worth, who owns each identity and who to contact, the steps your team runs for each alert type, and the verdicts your team has already reached. With those, it investigates the way your senior analyst would.
Q: How does an AI SOC Agent capture tribal knowledge? From the places your team already works: the Agent loads historical tickets and runbooks so past decisions carry over, turns each analyst verdict correction (with a short comment) into a context request, and accepts standing facts such as owner sheets, scanner subnets, and service accounts, one per request with a scope and a reason.
Q: How do you stop an AI SOC Agent from learning the wrong thing? Scope every entry to the hosts, accounts, or ranges you actually observed, state the reason, and put an expiry date on anything temporary. Then route every change through review, so a contradicting entry is held until a person resolves the conflict. An Agent that knows where an exception stops keeps investigating everything outside it, and a wrong fact runs out instead of becoming permanent.
Q: What are the security risks of AI Agent memory? The most serious is memory poisoning: if anyone can write "this is normal" into an Agent's memory, an attacker eventually will, and every matching alert is discounted after that. The other two are stale entries and over-broad exceptions. Tracked writes with before-and-after diffs, human approval for Agent-proposed changes, scoping, and expiry address all three.
Q: Does an AI SOC Agent need months to learn our environment? No. Simbian's AI SOC Agent arrives already competent in general defensive skill, so it investigates from the first alert, and its Context Lake starts filling from your tickets and runbooks in the first days of deployment. Your tribal knowledge then deepens with every case your team reviews.
Your logs will never record why svc-backup is fine. Write it down, scope it, give it an end date, and the next analyst, human or AI, closes BUILD-07 in thirty seconds too. To see your own tribal knowledge working on live alerts, book a demo and bring your noisiest alert type.
