An MSSP may manage security operations for dozens of customers through the same platform. Its analysts follow a common investigation method, work to shared quality standards and use established processes for escalation and reporting.
But the environments they protect are not the same.
One customer may operate hospitals where isolating a system could affect patient care. Another may be a technology company whose developers regularly use tools that would look suspicious elsewhere. One organisation may permit privileged access from several countries, while another expects administrators to connect only from a controlled corporate network.
The MSSP needs consistency across its service, but its agents need to understand the differences between customers.
The same challenge exists inside large organisations. A central SOC may protect several subsidiaries or business units, each with different systems, working practices and risk priorities. The organisation shares a security policy, but the activity considered normal in finance may be very different from what is expected in manufacturing or engineering.
This is the problem the Sekoia autonomous SOC set out to solve. Rather than giving security teams one flat agent configuration for every environment, the Sekoia Autonomous SOC makes it possible to customise agents at different levels of the operational hierarchy. An MSSP can establish a common approach across its service and refine it for individual customers. An organisation can define shared instructions and add more specific context for its business units.
The result is an agent that inherits the right standards without losing the local knowledge it needs to investigate accurately.
The problem with one global agent
The simplest way to deploy an AI agent is to give it one set of instructions and apply them everywhere.
That approach can work in a small, relatively uniform environment. It becomes far less useful in a multi-tenant SOC.
A global instruction might tell an agent to treat administrative activity outside business hours as suspicious. That could be appropriate for several customers, but misleading for an organisation with teams working across multiple time zones.
The instruction can be made more detailed by adding exceptions. The agent can be told which customer operates internationally, which service accounts run overnight and which suppliers are permitted to connect remotely.
Over time, however, the central configuration becomes a collection of assumptions about every environment the SOC manages. Context intended for one customer sits beside context for all the others. Instructions become harder to maintain, and there is a greater risk that local knowledge will influence the wrong investigation.
The alternative is to configure an entirely separate agent for each customer.
That keeps the environments apart, but creates another problem. Shared investigation standards have to be reproduced in every configuration. If the MSSP changes its escalation policy or improves its investigation method, that change must be applied separately to each agent.
One global configuration creates too much generalisation. Completely separate configurations create too much duplication.
The Sekoia autonomous SOC addresses both problems by allowing agent customisation to follow the structure of the SOC.
Define the common method once
An MSSP usually has an established way of delivering its service.
It may require every investigation to gather evidence before reaching a verdict, examine related activity and clearly explain the reasoning behind any escalation. It may have standard definitions for severity, confidence and false positives. It may also have contractual procedures that determine when customers are notified.
These instructions should not have to be recreated for every tenant.
Within the Sekoia autonomous SOC, the common operating model can be defined at the MSSP level, giving agents a shared foundation across the customers below it. When the provider improves that foundation, it can update the common instructions instead of maintaining many disconnected versions.
This allows the MSSP to scale its investigation expertise.
The same principle applies inside an enterprise. A central SOC can define organisation-wide expectations for how agents investigate, document findings and involve human analysts. Those expectations can then provide the foundation for agents working across different parts of the business.
Common instructions remain common. They are managed at the level where they belong.
Add local knowledge where it is true
A shared investigation method is only one part of what an agent needs.
To understand an alert, the agent also needs to know how the environment normally behaves. That knowledge is often specific to a customer, subsidiary or business unit.
An MSSP might know that a customer uses a particular VPN provider, has outsourced administration to a named supplier or treats a certain application as business-critical. Another customer may have a stricter escalation threshold or a different definition of privileged access.
Within a large organisation, the manufacturing business may need to explain the expected behaviour of operational technology. The engineering team may use development and automation tools that regularly produce unusual-looking activity. Finance may have its own critical periods, regulatory requirements and response procedures.
The Sekoia autonomous SOC allows that context to be added at the level where it applies.
The customer inherits the MSSP’s common investigation approach, while adding instructions that reflect its own environment. A business unit inherits the organisation’s security standards while contributing the operational knowledge needed to interpret its activity.
The higher level defines how the agent should investigate. The lower level helps it understand what the evidence means locally.
Customisation without duplication
Inheritance is what makes the model practical.
Without it, an MSSP that manages 50 customers may have to maintain 50 complete agent configurations. Even if most of those configurations contain the same instructions, each one becomes a separate item to review and update.
With multi-level customisation, the provider can define the shared portion once. Customer-level settings then contain only what is different about that customer.
This reduces the amount of configuration that must be maintained and makes the differences easier to understand. Instead of reviewing an entire agent configuration to find the relevant customer context, the team can focus on the instructions that have been added or adapted locally.
It also reduces drift.
When common instructions are copied, they gradually diverge. One customer configuration may contain the latest investigation method while another still uses an older version. A small change made for one tenant may never reach the others.
By keeping shared behaviour at the parent level, the Sekoia autonomous SOC gives teams a single place to improve it. The environments below can benefit from those improvements without losing their own context.
Consistent service does not mean identical investigations
For an MSSP, consistency is essential. Customers expect a dependable service regardless of which analyst is working or when an alert arrives.
But consistency should describe the quality and method of the investigation, not an assumption that every customer behaves in the same way.
Consider an alert involving a remote administration tool. The MSSP may want every agent to identify the user, examine the affected asset, review surrounding activity and establish whether the tool created persistence. That is the common method.
The customer context then shapes the conclusion.
For one organisation, the tool may be approved and widely used by its IT provider. For another, it may be prohibited. A third may permit it only on a defined group of systems.
The investigation remains consistent because the agent asks the same important questions and applies the MSSP’s evidence standards. The verdict can still differ because the environments are different.
This is the balance the Sekoia autonomous SOC’s multi-level approach is designed to provide: shared expertise without generic judgement.
Making customer knowledge part of the agent
MSSP analysts already accumulate detailed knowledge about the customers they protect.
They learn which applications matter most, which administrative patterns are expected and which alerts need immediate attention. They know about recurring false positives, maintenance windows, trusted suppliers and unusual but legitimate user behaviour.
Much of this knowledge traditionally sits in internal documentation, analyst notes or the memories of people who regularly work with the customer.
The Sekoia autonomous SOC gives providers a way to bring that knowledge into the agent’s operating context.
Instead of relying on an analyst to remember that a particular service account runs a scheduled task every night, the information can be made available to the agent responsible for investigating that customer. Instead of applying an escalation requirement manually, it can form part of the customer-level instructions.
This does not remove the analyst from the process. It makes the knowledge analysts have developed available earlier and more consistently during the investigation.
As the provider learns more about the customer, the agent can be refined with it.
A clearer model for governance
Customisation also needs boundaries.
As agents take on more investigative work, teams need to understand which instructions influence their behaviour, who owns those instructions and where they apply. Customer knowledge should not leak into another tenant’s investigation. A local business-unit exception should not quietly become an organisation-wide policy.
Organising agent instructions by level creates a clearer governance model.
The MSSP can own the service-wide method while customer-specific knowledge remains scoped to the appropriate tenant. A central security team can maintain organisational policy while individual business units contribute local context within their own boundary.
This makes it easier to distinguish a shared standard from a local exception. It also makes the agent’s behaviour more understandable when an analyst reviews an investigation.
If an agent treats an event as expected, the team should be able to connect that judgement to the context of the environment. If it escalates an alert under a customer-specific requirement, that influence should be intentional rather than hidden inside an oversized global configuration.
Multi-level customisation provides the structure needed to manage those decisions.
Built for the way modern SOCs operate
AI agents are often presented as if they work inside a single, self-contained environment.
Modern security operations are rarely that simple.
MSSPs deliver a shared service across customers with different technologies and risk profiles. Global organisations combine central governance with local operational knowledge. SOC teams need to standardise their methods while adapting their judgement to the environment in front of them.
The Sekoia autonomous SOC is designed around that reality.
Agents can be customised at the levels where security knowledge naturally exists. Common investigation standards can be defined centrally. Customer- or business-unit-specific instructions can be added locally. Expertise can be inherited without copying complete configurations, and local context can remain within the boundary where it is relevant.
This allows MSSPs to scale a consistent service without flattening the differences between their customers. It allows enterprises to apply common security standards without assuming that every part of the business operates in the same way.
A multi-tenant SOC should not have to choose between standardisation and customisation.
With multi-level agents, it can have both.
