Blog
Governing AI in the SOC: six questions to settle first
Before a model reads your security data, decide where it runs, what it may see, what it may do, how it is limited, how you stop it and how you will know what happened.
Security telemetry is among the most sensitive data an organisation holds. It names your users, your hosts, your suppliers and your weaknesses. Putting a language model in front of it is a governance decision first and a technology decision second.
Most of the debate about AI in the SOC is about capability. Can it summarise an incident? Can it write a query? Those questions matter less than the ones a CISO will be asked after something goes wrong. Where did the data go? Who allowed it? What did the model do?
Settle six questions before any model reads your data. Write the answers into policy, and check that the platform can enforce them.
1. Where does the model run?
There are two broad choices. A model inside your own boundary, on a server you operate. Or a cloud provider, reached over the internet.
A model inside your boundary keeps data on your network. A cloud provider can be the right choice too, but only if you know exactly which calls leave and can prove it afterwards.
Decide: which model locations are allowed, for which tenants or business units, and who can change that.
2. What may it see?
Not every value needs to reach a model for the model to be useful. Hostnames, internal addresses, account names and customer identifiers can often be masked without losing the point of the question.
Masking only works if the rules exist. A redaction feature with no rules configured passes everything through.
Decide: which values must be masked before any external call, who maintains the rules, and how you will test them.
3. What may it do?
Keep AI advisory. Let it explain, recommend and propose. Let actions follow a separate policy, with risk levels and approvals, that applies whether a person or a model suggested the action.
The same goes for content the model creates. A detection rule or a playbook written by a model should wait for a person before it does anything.
Decide: which outputs a model may produce, and the human step each one must pass before it takes effect.
4. How is it limited?
Models are metered. A runaway workflow or one noisy client can consume a budget meant for everyone. In a multi-tenant service, it can also mean one client's usage affects another's.
Decide: a usage budget per tenant, and what happens when it is reached. Refusing the request is better than a surprise bill.
5. How do you stop it?
There will be a day when you want AI egress off immediately. An incident involving a provider, a change in regulatory advice, or a simple doubt about what is being sent.
That switch needs to work quickly, without a restart, and it needs to fail safe. If the platform cannot read the setting, the answer should be "off".
Decide: who holds the switch, how fast it must take effect, and how you will rehearse using it.
6. How do you know what happened?
Every model call should leave a record: which tenant, which provider and model, when, how much was sent and how many values were masked, and whether the call went through. Blocked calls matter as much as successful ones. The record must never contain the API key.
Decide: what each AI audit record must contain, how long you keep it, and who reviews it.
A one-page policy
The answers fit on one page. For each question, write the rule, the owner and the evidence you will look at to prove the rule is working. Review it when you add a provider, a tenant or a new AI feature.
How kymeer approaches this
The kymeer AI analyst is advisory. It explains what it sees, recommends next steps and can propose playbooks; people decide what happens next.
Where it runs. You can point kymeer at a model server on your own network; calls to a loopback or private address are recorded as zero-egress. Cloud providers are also supported with your own API key. Provider keys are stored per tenant, encrypted with AES-256-GCM, never returned by the API, and set or revoked only by a platform administrator.
Four steps on every call, in order. An egress gate that is off by default and stays closed if its setting cannot be read. Built-in masking, which always runs: each IP address, hostname, email address and user name kymeer recognises becomes a numbered stand-in such as HOST_2, and the real values are put back into the answer before anyone sees it. Your own redaction patterns apply on top. A per-tenant token budget, so a request over budget is refused before it is sent. And an audit record for every attempt, including blocked ones, with the provider, model, token counts, tenant, time, number of masked values and outcome. The API key is never recorded.
The switch. AI egress is controlled by one platform setting held by the platform administrator. A change takes effect within 60 seconds, with no restart.
What it may do. In incident analysis, only citations the model selects from the evidence it was given are kept, and claims without a citation are rejected. A playbook proposed by the analyst is returned unsaved, any step that names an unknown action is dropped, and a person edits and saves it. A proposed detection rule is backtested against your tenant's recent events with the same engine that runs in production, and stays inactive until a person approves it.
Read the details in the AI analyst guide, or see the AI analyst page.