What this category of data looks like
Data for SOC duty scenarios comes from SIEM, EDR, NDR, and threat intelligence sources. Update cadences are split into real-time alert streams and daily summary documents. Daily generated documents include alert disposition sheets, on-call records, threat intelligence briefings, and daily/weekly reports. Fields include alert ID, disposition status, associated threat intelligence identifiers, team affiliation identifiers, and operation logs. Data is categorized by team and disposition group, with no default cross-team sharing configuration.
What constraints do these characteristics impose on permission and data isolation
Real-time alert streams require permission checks to meet low-latency requirements, and avoid blocking normal alert triage operations. Multi-source security data and layered documents require fine-grained isolation by team and role, to prevent cross-team access to sensitive threat intelligence and unprocessed alert tickets. Ticket assignment and escalation processes must be bound to team permissions, ensuring only authorized members can perform alert escalation and assignment operations, to avoid response delays caused by misoperations.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Team affiliation identifier synced with SIEM | Binds the owning team of alerts and tickets, enabling cross-team data isolation |
tmbId | Permission identifier bound to the member’s affiliated team | Core identifier for verifying member access permissions, matching team division rules |
| Team permission scope | Divided by alert disposition group, covers all security data of the team | Adapts to the business model of SOC teams on duty by group, narrows permission boundaries |
| Knowledge base association permissions | Only associate this team’s alert disposition sheets and threat intelligence briefings, maximum 1000 MB | Isolates security documents across teams, prevents cross-team data leaks |
| Data isolation timeliness | Real-time verification, latency no more than 1 second | Adapts to the update cadence of real-time alert streams, ensures triage efficiency |
| Member operation permissions | Assign view/edit/create permissions by role, only on-duty supervisors can configure global rules | Differentiates operation boundaries between SOC analysts and on-duty supervisors, prevents unauthorized operations |
Three common misconfigurations
- Phenomenon: When calling the interface associated with cross-team knowledge bases to query alert content, no relevant content is returned. Cause: The
teamIdbinding for the corresponding team’s knowledge base permissions is not configured, resulting in cross-team data isolation interception. - Phenomenon: Team administrators cannot view operation logs of members in their own team using the model. Cause: The permission audit switch associated with
tmbIdis not enabled, and the team permission identifier is not bound to the log query rules. - Phenomenon: Unauthorized members create agents and access SOC alert data from other teams. Cause: Member operation permissions are not divided by role, and the verification rules for team permission scope are not configured.
How to confirm the configuration is correct
- Log in to the FastGPT v4.17.0 backend, switch to different teams’
teamId, verify that only the alert disposition sheets and on-call records for the corresponding team can be viewed. - Submit a query request for a cross-team knowledge base, confirm that a no permission prompt or no matching results are returned, which complies with data isolation rules.
- Assign permissions to members of different roles, verify that only authorized roles can perform operations such as creating agents and editing alert tickets, and unauthorized roles cannot access the corresponding data.
- View member operation logs on the team management page, confirm that only records of model usage and ticket processing by members of the own team can be viewed.
The values listed here are common starting points, and should be evaluated against your own specific samples and use cases.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.