# Jutsu Documentation, full text # Getting Started URL: https://jutsu.ai/docs JUTSU AgentSOC User Guide --- # Introduction URL: https://jutsu.ai/docs/introduction Security operations teams typically juggle multiple disconnected tools -- a SIEM for log collection, a separate SOAR for response, external threat intelligence… About Jutsu Security operations teams typically juggle multiple disconnected tools -- a SIEM for log collection, a separate SOAR for response, external threat intelligence feeds, and standalone reporting. Switching between them slows investigations, creates gaps, and puts the burden of correlation on the analyst. Jutsu, through AgentSOC, replaces that fragmented stack with a single AI-native platform. Every event that enters the platform is automatically normalized, enriched against multiple threat intelligence sources, scored, triaged, and correlated into incidents -- without manual intervention. Your team focuses on the decisions that require human judgment. The AI handles everything else. The platform has two core components: AgentSOC -- The SOC platform covered in this guide. Alerts, incidents, cases, assets, Copilot, and reporting all live here. AgentSOAR -- The built-in response automation module covered in Part 4. It executes defensive actions against your connected cloud, email, and identity providers directly from the platform. --- # Onboarding Flow URL: https://jutsu.ai/docs/onboarding-flow Open the Jutsu sign-up page. Enter your full name, work email, and a password with at least 6 characters, then select Create account. Create your account Open the Jutsu sign-up page. Enter your full name, work email, and a password with at least 6 characters, then select Create account. Use an email address you can verify immediately. If the address already has an account, use Sign in instead. Continue with Google is available as an alternative and does not require a separate Jutsu email-verification step. Check your inbox After a standard email-and-password sign-up, Jutsu creates the account but does not sign you in yet. The confirmation screen shows the address that received the verification link and then redirects to sign in. Verification window: The email-verification link is valid for 24 hours and is single-use. Verify your email address Open the message from Jutsu and select Verify email address. This confirms that you control the address used for the account. If the message is not visible, check spam, junk, and corporate email filters. Open the newest verification message if you requested more than one link. Do not forward the verification link; it is intended for the account owner. Continue after verification A successful link opens the Email verified screen. Select Continue to sign in. Expired or invalid link: Enter your email on the verification screen and select Resend verification email to receive a fresh 24-hour link. Sign in Enter the verified email address and password, then select Sign in. You can also use Continue with Google when the account is connected to Google. The email and password fields are both required. An unverified email cannot sign in until verification is complete. Use Forgot password? if you no longer know the password. Choose a plan Jutsu sends users without an organization to onboarding. Review the available plans and select the card that matches your expected team size, protected assets, data capacity, and retention needs. Free plans create the workspace immediately. A purchasable paid plan creates a preview workspace and then offers Continue to payment. A plan marked Request access starts the workspace on Free and submits an upgrade request. Plan availability, prices, and limits can change; use the values shown in the product when you sign up. Name your organization Enter the organization profile. Jutsu auto-generates a unique workspace slug from the name and checks its availability before enabling Continue. Organization name - required; this is the name teammates see. Slug - required; 3-80 lowercase letters, numbers, and single hyphens. It must be available. Company size and estimated assets - required; these are planning estimates and do not by themselves change your plan limits. Company URL, industry, and primary use case - optional and editable later. Choose the workspace region Select the region where workspace events and detections will be stored. The United States region is currently live; other listed regions are marked Soon. Data residency decision: A workspace cannot be moved to a different region later. Create a new workspace if future residency requirements change. Wait for workspace provisioning Select Create organization. Jutsu shows real provisioning milestones as it creates the organization, applies plan capacity, installs detection rules, and finalizes the workspace. Keep the page open while setup completes; normal setup usually takes a few seconds. If setup fails, select Try again and review the organization details before retrying. A paid plan may pause on an activation screen so you can continue to payment or explore the preview workspace first. Continue when the workspace is ready When setup finishes, Jutsu confirms that the workspace is ready. Select Invite your team to continue, or choose I'll do this later to move directly to asset connection. Skipping is reversible: You can invite teammates later from Organization > Team. The dashboard setup checklist continues to track this task. Enter the teammate's email address Type the work email address of the person you want to invite. The invitation is permanently bound to that address, so confirm the spelling before sending. Select Add another to invite more teammates in the same batch. Empty rows are ignored; a non-empty row must contain a valid email address. Each pending invitation reserves a plan seat until it is accepted, declined, revoked, or expires. Seat limit: If the batch exceeds your plan's seat allowance, Jutsu identifies the affected rows and offers Request an upgrade. Choose the role and send invitations Open the Role picker for each teammate, choose the least-privileged role that supports their work, and then select Send invites. Owner is not assignable: A workspace has one Owner. Ownership moves only through an explicit ownership transfer and cannot be selected in an invitation. Connect the first asset Choose a host or cloud integration to start streaming events into Jutsu. Select a catalog item and follow its connection dialog, or choose Skip for now. An asset can be a host collector or a cloud/SaaS integration. Jutsu marks this onboarding task complete after at least one asset or integration becomes Active. Connecting assets requires the Admin or Owner permission level. Lower roles can browse the catalog but cannot create the connection. Skipped connections can be added later from Integrations > Data Sources. Open the dashboard and follow the product tour After asset connection or Skip for now, Jutsu opens the dashboard. On the first visit, a guided tour introduces the visible dashboard areas and account controls. Select Next to follow the tour, or Skip tour / close it to dismiss it. Tours run once per page for each user; unavailable targets are skipped automatically. The dashboard setup checklist tracks five outcomes: organization created, detection rules explored, team invited, asset connected, and first alert reviewed. You can dismiss the checklist with its close control when you no longer need it. How invited teammates join The recipient should start from the Accept invitation link in the invitation email. The landing page previews the organization, inviter, assigned role, and invited address before asking the person to authenticate. New Jutsu user - select Create account & join. The invited email is locked in the form. A valid invitation verifies the new account, accepts the invitation, and signs the user in without a separate verification email. Existing Jutsu user - select Sign in & join. After successful sign-in, Jutsu returns to the invitation and presents Accept invitation. Already signed in with the invited address - select Accept invitation. Jutsu adds the organization and makes it active. Signed in with a different address - select the option to sign out, then sign in with the address that received the invitation. Pending invitations during onboarding A signed-in user who does not yet belong to an organization can also see pending, unexpired invitations addressed to their email. They may Accept, Decline, or choose Create a new organization. Invitation validity: Invitations expire after seven days. Admins and Owners can resend or revoke pending invitations from Organization > Team. Sign-in and onboarding recovery Email is not verified - open the verification message. If the link expired, use Resend verification email on the verification screen. Password is forgotten - select Forgot password?, enter the account email, and open the reset message. Reset links expire after one hour; completing a reset signs out other active sessions. Organization slug is unavailable - edit the slug until Jutsu shows Slug is available. Workspace setup fails - select Try again and review the plan, name, slug, and required organization profile fields. Invitation was sent to the wrong email - ask an Admin or Owner to revoke it and send a new invitation to the correct address. Invitation expired - ask an Admin or Owner to resend it; the new validity window is seven days. Seat limit reached - remove an unused pending invitation, wait for it to expire, or request a plan upgrade before inviting more people. Asset connection was skipped - open Integrations > Data Sources when you are ready to connect one. Security guidance Use a unique password and keep your email account protected; the minimum accepted password length is 6 characters. Do not share verification, password-reset, or invitation links. Each link authorizes a specific account action. Assign the lowest role that supports the teammate's work. Use Admin only for people who manage integrations, rules, members, or settings. Verify the organization name, invited email, inviter, and role before accepting an invitation. Sign out from shared devices. Account settings include active-session controls for reviewing and revoking sessions. --- # Your Account URL: https://jutsu.ai/docs/setup/your-account Settings controls your account profile, timezone, password, and notification preferences. Access it by clicking the Settings icon at the bottom of the left sid… Your Account Settings controls your account profile, timezone, password, and notification preferences. Access it by clicking the Settings icon at the bottom of the left sidebar. Path: Settings icon at the very bottom of the left sidebar. Profile Display name Click Full name, type your name, click Save Changes. Your name appears on case assignments, discussion notes, and the Seen by field on alerts -- so teammates can see who has reviewed what without asking. Timezone Click the Timezone dropdown, select your local timezone, click Save Changes. Every timestamp in Jutsu/AgentSOC -- alert detection times, case creation, event logs -- converts to this timezone immediately. Set it before you look at a single alert. Timezone and timestamps: Every timestamp in Jutsu/AgentSOC -- alert detection times, case creation, event logs -- reflects your configured timezone. Setting it accurately before your first session ensures incident timelines are reliable. Password Scroll to the Password and sign-in card. Enter your new password in the Set Password field. Enter it again in Confirm Password, then click Set Password. The change takes effect immediately. Email and Role Both fields are read-only. Email and Role are managed by your administrator and cannot be changed from this screen. If either is incorrect, contact your administrator. Notifications Click Notifications in the Settings sidebar. Four toggles control which components send you an email. Alerts toggle -- Email notification when a new alert is created. Incidents toggle -- Email notification when a new incident is created. Cases toggle -- Email notification when a case is assigned to you or updated. Reports toggle -- Email notification when a report is ready to download. --- # Organizations URL: https://jutsu.ai/docs/setup/organizations Click your organization name at the bottom left of the sidebar. A popover appears showing all organizations you belong to, with the currently active one marked… Accessing Organization Click your organization name at the bottom left of the sidebar. A popover appears showing all organizations you belong to, with the currently active one marked with a checkmark. Three options appear at the bottom of the popover: Open organization -- Opens the Organization Overview page. Organization settings -- Takes you directly to the Organization Settings page. View all -- Shows all organizations you are a member of. If you belong to multiple organizations, click any organization in the list to switch to it. Overview The Overview page shows a summary of your organization workspace. The header displays your organization name, slug, website, and an Active status badge. Three buttons sit in the top right: Settings -- Takes you directly to the Organization Settings page. Manage team -- Takes you directly to the Team page. Leave -- Removes you from this organization. Summary cards Members -- Total number of teammates in the organization. Owners -- Number of users with full control over the organization. Admins -- Number of users with elevated access. Your role -- Your current role in this organization and the date it was assigned. About Displays the organization description, creation date, status, website, and Org ID. The Org ID is the unique identifier for this organization used in API calls and support references. People here Lists the members currently in the organization with their email address and role. Click View all to see the full team list. Settings The Settings page configures how your organization looks, integrates, and notifies your team. General information The basics that teammates and integrations see across the platform. Click Save changes to apply any updates. Organization name -- The display name of your organization as it appears across the platform. Slug -- A short, URL-safe identifier for your organization. It is automatically generated from your organization name and is prefixed with @. It appears in your organization's URL and is used by the platform to reference your organization internally. Website -- Your organization's website URL. Description -- A plain-text description of your organization. Branding Logo and cover images for your organization profile. Logo -- A square avatar image displayed in dashboards, invitations, and handoffs. Recommended size: 512x512px. Cover image -- A banner image displayed on your organization profile. Recommended size: 1600x400px. Click the upload area for either image to select a file from your device. Team -- Members & Access The Team page manages members, roles, and pending invitations for your organization. The header shows four counters: Members, Owners, Admins, and Pending. Invite teammates Enter a teammate's email address in the input field, select their role from the dropdown, and click Send Invite. They receive a magic-link invitation and join with the role you selected. Members Displays all current members as cards. Each card shows the member's name, email address, role badge, and active status. Your own card is labeled YOU. For other members, two controls appear on their card: Role dropdown -- Change the member's role directly from the card. Takes effect immediately. Delete icon -- Removes the member from the organization. Pending join requests Shows any users who have applied to join the organization. Approve or decline each request from here. Pending invitations Shows invitations you have sent that have not been accepted yet. If a teammate did not receive their invitation or needs it resent, it will appear here. The role dropdown on each member card shows three options: Admin -- Administrative access. Can manage members, configure integrations, and adjust platform settings. Analyst -- Security analyst access. Can review alerts, work cases, and investigate incidents. Member -- Standard access. Can view the platform and work within their assigned organization. Model Selector The Model Selector page lets administrators configure which AI model powers each role in the platform pipeline. There are 7 slots in total -- one for each AI function. Values apply across the entire organization and workers read the same catalog and encrypted overrides at runtime. Header 7 slots -- The total number of configurable AI roles in the platform. 0 on default / 7 customized -- Shows how many slots are using default settings and how many have been customized. Last change -- The date and time the configuration was last updated. Search -- Filters slots by slot name, ID, or reference. Set all slots -- Applies one provider and model selection to all seven slots at once. Refresh -- Reloads the current configuration from the server. Save all -- Saves and applies all pending changes across every slot. Each slot card Each slot is displayed as a card with the following: Slot name and icon -- The name of the AI role, for example Platform Copilot. Internal ID -- The identifier used by the platform to reference this slot. Description -- A plain-language explanation of what this AI role does in the pipeline. Custom badge -- Appears when the slot has been changed from its default configuration. Reset -- Reverts that slot back to its default setting. Provider dropdown -- The AI provider for this slot, for example OpenAI or Anthropic. Key -- The API key environment variable used to authenticate with the selected provider. Model dropdown -- The specific model from the selected provider. Each option shows the model name and its token pricing in the format input cost / output cost per 1M tokens. The currently selected model is marked with a checkmark. Use custom model id toggle -- When enabled, allows entering a custom model identifier manually instead of selecting from the dropdown list. The seven slots Platform Copilot (copilot) -- Powers analyst chat and assisted reasoning in the platform -- answers, explanations, and drafting grounded in your data. Triage (triage) -- Classifies each alert in the events-triage pipeline -- verdict, priority, and confidence -- before correlation and automated response. Enrichment (enrichment) -- Adds AI context to alerts -- entities, phishing hints, and supporting analysis -- so triage and investigation start with richer signal. Incident correlation (incidentcorrelation) -- Groups related alerts into incidents, breaks ties when models disagree, and drafts incident titles and attack narratives. Response (response) -- Chooses the best-matching SOAR playbook or response path when automation needs an AI model to decide how to act. Incident report generator (incidentreport) -- Produces structured incident write-ups including executive summary, timeline, and analytic narrative. Org reporting (reporting) -- Generates scheduled organization reports with metrics and plain-language commentary for leadership and compliance readers. Available models The following OpenAI models are currently available: GPT-5.2 -- $7.5 in / $22.5 out per 1M tokens. GPT-5.4 mini -- $0.3 in / $2.4 out per 1M tokens. GPT-5 -- $5 in / $15 out per 1M tokens. GPT-5 mini -- $0.25 in / $2 out per 1M tokens. Each model option displays its price per 1 million tokens so you can balance cost against capability when configuring each slot. --- # The Pipeline URL: https://jutsu.ai/docs/orientation/the-pipeline By the time something reaches your queue, a chain of AI agents has already run a full investigation. Understanding what each agent does helps you read the plat… How the AI Works -- The Pipeline By the time something reaches your queue, a chain of AI agents has already run a full investigation. Understanding what each agent does helps you read the platform's output accurately and know which parts are AI conclusions versus raw data. The chain at a glance: Raw log event → Normalize → Enrich with threat intel → Score and triage → Correlate with related alerts → Route (human or auto-close) → Generate incident report. That entire chain runs automatically for every event. You see the finished output. 1. Ingest Your connected SIEM sends raw events to Jutsu/AgentSOC's Ingest API continuously. The Ingest API validates and accepts each one. Sources can include Wazuh, Google Workspace Email Logs, Syslog, and custom webhooks. 2. Normalize The Normalizer reshapes every event into a consistent internal format. An SSH failed login from Wazuh and a failed email login from Google Workspace are different raw log formats -- after normalization, they look identical to every downstream agent. This is what makes cross-source correlation possible. Normalized events are stored in OpenSearch in a per-organization, weekly index. This is the data store underlying every Events, Alerts, and Incidents view in the platform. 3. Enrich The Enrichment agent queries all nine TI providers for every observable in the event: IPs, file hashes, domains. It also checks your asset inventory and identity data. After this step, the platform knows whether the source IP has a bad reputation, what country it is in, whether the target host is internet-facing, and more. 4. Triage The Triage agent assigns a risk score (0-100), a verdict (True Positive, False Positive, or Not Sure), and maps the activity to MITRE ATT&CK techniques. 5. Correlate The Incident Correlation engine looks across all recent enriched alerts for patterns -- same attacker, same target, same technique, overlapping time window. Related alerts get grouped into an Incident. A single campaign across multiple hosts might generate 50 individual alerts; correlation surfaces all of it as one event. 6. Respond The Response agent decides what to do: escalate to your team as a Case (when confidence is insufficient), run an automated AgentSOAR playbook (when confident and automation is configured), or close automatically (when clearly benign). This decision is visible in the SOAR Response panel on every alert. 7. Report For incidents, a Security Incident Report is generated automatically: campaign summary, executive summary, and recommended next steps. What this means for you: When you open an alert, all seven steps have already run. The AI Verdict, enrichment results, MITRE mapping, risk score, and SOAR response are all pipeline outputs. You are reviewing a finished analysis and deciding whether to act, investigate further, or close. --- # Dashboard URL: https://jutsu.ai/docs/orientation/dashboard The Dashboard is the first screen after login and your daily starting point. In under a minute you can see how busy today is, whether anything critical is open… Start Here – Dashboard The Dashboard is the first screen after login and your daily starting point. In under a minute you can see how busy today is, whether anything critical is open, and whether the AI has created Cases waiting for your team. Path: Dashboard at the top of the left sidebar (opens automatically on login). Time Range Every number on the Dashboard reflects the selected time window. Default is Last 24 hours. Click the time range button (top right) to change it -- presets from Last 1 hour to All time, plus Custom Range. The Global Sync toggle at the bottom of that dropdown applies your window to every page in the platform simultaneously. If numbers show zero: Check the time range. Expanding to Last 7 days is a good first step when the dashboard appears empty. The Six Metric Cards Total Events -- Every raw log entry received from your connected systems in the selected period -- logins, file access, network connections, and emails. Reflects the full volume of data the AI worked through. Processed Alerts -- How many of those events the AI flagged as suspicious enough to investigate. The ratio between this and Total Events reflects how efficiently the AI is filtering signal from noise. Click the card to open the Alerts list. Mean Time to Detect (MTTD) -- How fast the platform catches threats. It measures the average time between a threat occurring and an alert being generated. The lower this number, the faster threats are being detected in your environment. The platform shows an industry average of five minutes so you can benchmark your detection speed. Time Saved -- The estimated number of analyst hours the AI has saved in the selected period by automatically handling normalization, enrichment, triage, correlation, and routing -- work that would otherwise fall on your team. Starts at zero on new deployments and grows as the platform processes more volume. Escalated to Human -- The number of alerts the AI investigated but could not confidently resolve on its own. These have been converted into Cases and assigned to your team for human judgment. If this number is non-zero, Cases are waiting. Click the card to go directly to the Cases queue. Mean Time to Resolve (MTTR) -- The average time from when an alert is detected to when the resulting Case is closed. This reflects how quickly escalated investigations are being handled. The platform shows an industry average of three hours for comparison. Click the card for a breakdown of resolution time by stage. Events Breakdown by Severity Shows the distribution of alerts across five severity levels: Critical, High, Medium, Low, and Info. Each row displays a count, a percentage of total alerts, and a color-coded progress bar. Click the external link icon next to any severity level to jump directly to the Alerts list filtered to that severity. Geographic Threat Map Plots attacker locations, your asset locations, and the paths between them on a world map. The counter in the top right shows the total number of countries with active threat activity. The Top 5 countries by threat volume panel lists the highest-activity source countries with their alert counts. Hover over any point on the map to see location details. Top Attackers, Top Hosts, Top Attacks Top Attackers -- Lists the most active threat sources in the selected period, ranked by alert count. Each entry shows the source IP address and its total alert count. The counter in the top right shows the total number of unique sources detected. Top Hosts -- Lists the most targeted internal assets, ranked by alert count. Each entry shows the hostname, IP address, and total alert count. The counter in the top right shows the total number of targeted hosts. Click any host to see its related alerts. Top Attacks -- Lists the most common attack techniques observed, ranked by alert count. Each entry shows the technique name, a brief description, and its total alert count. The counter in the top right shows the total number of distinct attack types detected. MITRE ATT&CK Framework Coverage MITRE ATT&CK is a publicly maintained framework cataloguing every tactic and technique used by real-world attackers. Tactics are high-level goals (like Initial Access or Lateral Movement). Techniques are the specific methods used to achieve them (like SSH brute force or pass-the-hash). Jutsu/AgentSOC maps your detected alerts to this framework automatically. Coverage shows how your alert activity maps across the fourteen top-level tactics. Each tile is color-coded: High Coverage (75%+), Medium (50-75%), Low (25-50%), Minimal (<25%), No Coverage. Click any tactic tile to see the technique-level breakdown. Compliance Framework Mapping Maps your security activity against three regulatory frameworks: NIST, GDPR, and HIPAA.Click any tab to switch between frameworks. NIST -- The National Institute of Standards and Technology Cybersecurity Framework. A set of guidelines and best practices for managing cybersecurity risk, widely adopted across industries in the United States and globally. GDPR -- The General Data Protection Regulation. A European Union regulation governing how organizations collect, store, and protect personal data. Applies to any organization handling data of EU residents. HIPAA -- The Health Insurance Portability and Accountability Act. A U.S. regulation requiring healthcare organizations and their partners to protect the privacy and security of patient health information. Each framework tab shows an overall compliance score as a ring chart, broken down into four counters: Compliant -- Controls fully satisfied based on current alert and detection activity. Partial -- Controls where some requirements are met but gaps remain. Non-Compliant -- Controls with no evidence of the required activity. Total -- Total number of controls mapped for this framework. Control Details -- Lists individual controls below the score. Each control card shows the control ID (e.g. ID.AM-1), a description of what the control requires, a status icon (green checkmark for compliant, yellow warning for partial, red cross for non-compliant), an alert count showing how many alerts are contributing to that control's status, and a color-coded progress bar reflecting coverage level. Click any control card to see the specific alerts mapped to it. --- # Alerts URL: https://jutsu.ai/docs/operations/alerts Click any row in the Alerts list to open the Alert Detail. This is the full output of the AI pipeline for that specific event. Inside an Alert – Alert Detail Click any row in the Alerts list to open the Alert Detail. This is the full output of the AI pipeline for that specific event. Check the case banner first If the banner shows 'Internal investigation case #[N] is open for this alert,' a Case already exists. Click Open case and work the investigation there. Investigating on the alert directly just duplicates work. Risk Summary The Risk Summary panel on the left shows the following: Risk score -- A number from 0 to 100 displayed in large text with a severity label below it. In this example the score is 70, labeled High severity risk. Click the question mark icon next to the score to open the Score Breakdown, which explains exactly how the score was calculated. MTTD -- Mean Time to Detect for this specific alert. Click the question mark to see how it is measured. MTTR -- Mean Time to Resolve for this specific alert. Click the question mark to see how it is measured. Confidence -- How certain the AI is about its verdict, as a percentage. 80% means the AI had strong, consistent signal from multiple independent sources. Detected at -- How long ago this alert was first generated, for example "3 hours ago." Alert metadata tags Below the toolbar: the Category tag (attack type, e.g. Brute force), Source tag (originating tool, e.g. Wazuh), Verdict tag (AI classification), and SIEM Severity tag (priority assigned by the originating SIEM). The Seen by avatars show which teammates have already opened this alert. Alert ID and copy button The Alert ID shown in the alert metadata includes a copy button. Click it to copy the full alert identifier to your clipboard -- useful when referencing an alert in a support ticket or discussion note. Score Breakdown The Score Breakdown is computed deterministically from the evidence below -- the same inputs always produce the same scores. The AI explains this result but cannot change it. Risk -- /100 Six factors contribute to the risk score, each with a maximum possible value: Threat Intelligence -- How many TI providers flagged the observables and at what confidence. Maximum 30. Detection evidence -- The strength and specificity of the rule that triggered. Maximum 20. MITRE ATT&CK context -- Whether the matched technique was confirmed by enrichment or inferred by the AI. Maximum 15. Correlation strength -- How many related alerts exist for the same attacker or target. Maximum 15. Vulnerability / exposure -- Whether the affected system is internet-facing or otherwise exposed. Maximum 10. Attack velocity -- How many related events occurred in a short time window. Maximum 10. The formula at the bottom shows how the final score is derived from the raw score, adjusted by asset weight and pipeline stage. Confidence -- /100 Three factors contribute to the confidence score: Evidence quality -- How strong and reliable the available evidence is. Maximum 40. Evidence coverage -- How much of the expected evidence was present. Maximum 30. Source reliability -- How trustworthy the contributing data sources are. Maximum 20. A threshold note below the confidence factors explains the verdict logic -- for example, a risk score in the 60-79 range with confidence at or above 70 is classified as a confirmed true positive. Contributing Evidence Lists the specific signals that increased the AI's confidence in its verdict. Each item explains what was found and why it supports the conclusion. Missing Evidence Lists the information the AI did not have that would have strengthened or potentially changed its verdict. Use this as your investigation checklist -- these are the gaps worth looking into before making a final decision on the alert. The scoring engine version and configuration version are shown at the bottom of the panel. Toolbar actions Mark as false positive (red) -- Closes the alert as confirmed benign and sends feedback to the AI. Only use when you are certain after reading the full analysis. Talk with AI (teal) -- Opens the Copilot panel pre-loaded with context from this alert. Overview Tab The Overview tab contains the AI's complete investigation output. It is active by default. AI Verdict A plain-language narrative written by the AI covering what was detected, what each threat intelligence provider returned, and why the risk score and verdict were assigned. Read this fully before taking any action on the alert. The Recommendations button Appears in the top right of the AI Verdict section. Click it to expand the AI's specific suggested next steps for this alert. MITRE ATT&CK Lists the MITRE ATT&CK technique IDs the AI matched to this alert. Each entry shows: Technique ID -- The unique MITRE identifier, for example T1110.001. Technique name -- The name of the attack technique, for example Password Guessing. Enrichment label -- Indicates whether the technique was confirmed by enrichment data or inferred by the AI. Techniques without a label were directly confirmed. Techniques labeled AI-inferred were identified by the AI based on behavioral patterns rather than direct evidence. Click any technique ID to open its full description on the MITRE ATT&CK website. Entities and SOAR response panel Every system, user, and IP involved in this alert, each with its role: Attacker IP, Victim Host, or Targeted User. A Privileged badge marks accounts with elevated permissions. Find resource identifiers here when filling in AgentSOAR action forms. SOAR Response Actions -- What the AI did. Case created means a Case has been opened for human investigation. Click the link icon to go directly to that case. Escalated -- Confirms whether the alert was escalated to a human analyst. Yes means a Case exists and is waiting in the Cases queue. Attack Timeline The Attack Timeline shows the chronological sequence of events that led to this alert. The header shows two values: the total time window from the first event to the last, and the total number of attempts recorded within that window. Each row shows a timestamp and a description of what occurred at that moment, including the Wazuh rule that fired and its corresponding MITRE technique ID where applicable. The attacker IP address is highlighted in the timeline to make it easy to identify. The final entry shows when the alert was escalated and a case was opened. The timeline is useful for understanding the pace and pattern of an attack. A short window with a high attempt count indicates a fast, automated attack. A long window with fewer attempts may indicate a slower, more deliberate approach designed to avoid detection thresholds. Threat Intelligence and Blast Radius Shows the results from each threat intelligence provider that returned data for the observables in this alert. Each provider card displays the provider name, a malicious confidence percentage, a color-coded progress bar, and a View details link to see the full provider response. A sources disagree badge appears in the top right when providers reach conflicting conclusions about the same observable. When this badge is present, review each provider's result individually rather than relying on a single source before making a decision. Geo Location -- The country and city associated with the source IP address. Org / ISP -- The organization or internet service provider that owns the IP address. Blast Radius Shows the broader reach of this threat beyond the single alert. The counter in the top right shows how many factors contribute to the blast radius assessment. Two panels are shown: Attacks from source IP in last 24h -- The total number of attacks originating from the attacker's IP address across your environment in the last 24 hours. A high number indicates the attacker is actively and broadly targeting your organization. Attacks to the victim host in last 24h -- The number of unique attack types and total attack attempts directed at the targeted host in the last 24 hours. A high number indicates the host is under sustained pressure from multiple attack vectors. Enrichment Tab The Enrichment tab shows the detailed output of the AI's classification and threat intelligence analysis for this alert. AI Classification Shows how the AI categorized this alert. The category is displayed as a badge next to the Category Analysis heading. Reasoning -- A plain-language explanation of why the AI assigned this category, based on the normalized event fields, rule metadata, and observables extracted from the alert. Model Confidence -- How confident the AI is in its category assignment, on a scale of 0 to 100. A higher percentage means the AI had strong supporting evidence for this classification. Threat Intelligence Summary Shows the AI Confidence score for the overall enrichment findings in the top right. Below that, the Summary section contains a full narrative written by the AI covering: What the originating SIEM rule detected and how many times it fired. What the raw log entries showed. What each threat intelligence provider returned for the source IP, including reputation scores and geolocation. How much attack activity has been seen from the source IP in the last 24 hours. Which MITRE ATT&CK techniques the activity maps to. Whether a successful login or compromise was detected in the available logs. An assessment of the overall situation and recommended actions. How far could this spread? The AI's assessment of the potential impact if this threat were to succeed. It describes which hosts or accounts are at risk, whether any indicators of lateral movement were observed, and how contained or widespread the threat appears to be based on available evidence. Did a compromise happen? The AI's assessment of whether an actual compromise occurred. It describes what the logs showed, whether a successful login or established session was detected, and whether the evidence confirms or rules out a compromise. This helps prioritize urgency -- an unconfirmed compromise requires a different response than a confirmed one. Attack Context Shows how much related activity has been seen in the last 24 hours, split into two panels: Attacks from Source IP -- The total number of alerts and unique normalized alert types generated by the attacker's IP address across your environment in the last 24 hours. Also lists the related Alert IDs for direct reference. Attacks to Host IP -- The total number of alerts and unique normalized alert types targeting the victim host in the last 24 hours. Also lists the related Alert IDs. Sources consulted Lists which threat intelligence providers were queried during the enrichment of this alert. The counter in the top right shows the total number of sources consulted. Each provider card shows the provider name and the type of intelligence it provides -- for example IP abuse reports, multi-engine scanning, or geolocation enrichment. IP Reputation -- Network Intelligence Shows the reputation results from each threat intelligence provider for the source IP identified in this alert. Provider Insights Displays the source IP address being assessed, followed by a card for each provider that returned data. Each card shows the provider name, a malicious confidence percentage, a color-coded progress bar, and a View details link to see the full raw response from that provider. IP Geolocation -- Geographic Location Data Shows the physical location and network ownership details for the IP address. Each entry is labeled with its role in the alert -- for example Attacker (Source) -- and a country code badge. The following fields are shown: Country -- The country the IP address is registered in. Region -- The region or state within that country. City -- The city associated with the IP address. Coordinates -- The latitude and longitude of the IP address location. Timezone -- The timezone of the IP address location. ISP -- The internet service provider that owns the IP address. Organization -- The organization registered to that IP address. Content, Raw, and Logs Tabs Content tab All structured data fields extracted from this alert in labeled sections: Alert Type, Alert Details, Host and Agent information, Network information, Rule Details from the originating SIEM, extracted Observables, the full Triage Decision block, and the Enrichment Summary. Use this when you need specific field values or want data to share with a colleague or Jutsu support. Raw tab The complete JSON payload as Jutsu received it, before any processing. Use the search field to filter. Click Copy for the full JSON. Use this when verifying what the AI worked with, when an alert processed unexpectedly, or when Jutsu support asks for the original payload. Logs tab A timestamped log of every processing step the pipeline ran on this alert: enrichment start, triage decision, case creation. Use this when troubleshooting an alert that processed unexpectedly. Copilot Panel Click Talk with AI at the top of any Alert Detail to open the Copilot panel, pre-loaded with context from this specific alert. Click Talk with AI. Use 'Summarize this alert' for a plain-language breakdown. Use 'Investigate an IP in this alert' for IP reputation context. Or type your own question and click Send. Click the toggle to close the panel. Copilot and verification: Copilot provides analysis based on available context. For high-stakes decisions, cross-reference its output against the underlying alert data and threat intelligence results in the platform. --- # Cases URL: https://jutsu.ai/docs/operations/cases A case is a formal human investigation task. Jutsu creates one automatically when the AI escalates an alert it could not confidently resolve. Cases are your pr… Own the Investigation -- Cases A case is a formal human investigation task. Jutsu creates one automatically when the AI escalates an alert it could not confidently resolve. Cases are your primary daily work, and everything you document here becomes the permanent investigation record. Path: Cases in the left sidebar. The Cases List Filters All Status -- Filters cases by workflow stage. Options: Open, In Progress, Pending, Resolved, Closed. All Severity -- Filter by severity: Critical, High, Medium, Low, Info. Assigned to me -- A toggle. When on, the list shows only cases assigned to your account. Show -- Controls how many rows appear per page. Options: 10, 20 (default), 50, 100. Previous / Next -- Navigate between pages when the list spans more than one page. Table view / Card view -- Two toggle buttons at the top right of the list. Table view (default) shows compact rows. Card view shows larger cards with more detail visible before clicking in. Search cases -- Free-text search across case titles. Case Detail Click any case row to open the Case Detail. Priority banner The priority banner shows how urgently a case needs attention. Priorities are assigned automatically based on the severity and confidence of the underlying alert. P1 -- Critical. Act immediately. The threat is confirmed or highly likely and requires urgent containment. P2 -- High. Investigate today. Strong indicators of a real threat that needs prompt attention. P3 -- Medium. Investigate when P1 and P2 cases are clear. Suspicious activity that warrants review but is not immediately critical. P4 -- Low. Review when capacity allows. Low-confidence or low-severity activity that still needs a human decision. Source and tags Alert ID links back to the underlying alert. Escalated confirms the AI routed this from triage. Alert linked confirms the underlying alert is still active and connected. Changing status Click the Status dropdown in Actions. Options: OPEN (active, unattended), IN PROGRESS (you are working it now), PENDING (waiting on information), RESOLVED (investigation complete), CLOSED (no further action). Keep this updated -- teammates should know the status without asking. Reassigning Click the Assigned to dropdown and select a teammate. The case appears in their queue immediately. Resolve button The Resolve button at the top right of a Case Detail marks the case as resolved and closes it. Resolved cases cannot be reopened. Document your findings in the Discussion tab before clicking Resolve. Case record: Resolved cases cannot be reopened. The Discussion tab is the permanent investigation record. Documenting findings there before resolving ensures the case has a complete audit trail. Overview Tab Escalation Reason The AI's explanation of why it could not resolve this alert and exactly what needs to be answered to close the case. Read this first. It tells you what to investigate. AI Summary Full investigation narrative: what was detected, what enrichment showed, the AI's verdict with reasoning. Same content as the AI Verdict on Alert Detail, presented here so you do not need to switch tabs. Linked Alert card The underlying alert's title, severity, status, rule number, and timestamps. Click View alert to open the full Alert Detail with all five tabs. Related Incidents If this case's alert is part of a broader campaign, related incidents appear here. 'No incidents are linked' means this is an isolated investigation. Evidence, Timeline, and Discussion Evidence tab Click Add evidence to attach files, screenshots, exported logs, network captures, or other investigation materials. The dropdown arrow on the Add evidence split button reveals additional attachment options. Everything attached is preserved permanently in the case record as part of the audit trail. Timeline tab An automatic, immutable log of everything that happened to this case: every status change, reassignment, evidence upload, and discussion comment, with timestamps and the name of whoever made each change. You do not add to it directly -- it builds itself. Discussion tab Where you document your investigation findings, communicate with teammates, and record the reasoning behind your close or escalation decision. Click the Write a comment field. Document what you investigated, what you found, what you ruled out, and what you concluded. Click Send. A complete note covers what was investigated, what evidence was found, what was ruled out, and the conclusion. For example: 'Source IP 43.160.253.60 confirmed malicious by AbuseIPDB (100%) and OTX (60%). GreyNoise classifies this as targeted, not background scanner noise. Host is internet-facing on port 22. Blocked source IP at network perimeter. Verdict: True Positive.' --- # Incidents URL: https://jutsu.ai/docs/operations/incidents An incident is what happens when the AI's Incident Correlation engine detects that multiple alerts belong to the same attack campaign. A single alert is one da… See the Full Campaign -- Incidents An incident is what happens when the AI's Incident Correlation engine detects that multiple alerts belong to the same attack campaign. A single alert is one data point. An incident shows the complete picture: every related event grouped together, the full attacker timeline, all affected systems, and the AI's campaign-level analysis. One attacker running a distributed brute-force campaign across multiple hosts might generate 50 individual alerts -- those become one incident. Path: Incidents in the left sidebar. The page defaults to Last 30 days. Expand the time range if you want to see a longer history. The Incidents List Summary cards Critical Incidents -- The number of critical-severity incidents in the selected time range. Active Incidents -- Open incidents that still need action. These are investigations in progress. Total Incidents -- All incidents captured in the selected time window, regardless of status. Resolved Incidents -- Incidents that have been moved through investigation and closure. Filters All Status -- Filters incidents by their current state. Options are Active, Resolved, and Closed. All Severity -- Filters by severity level. Options are Critical, High, Medium, Low, and Info. Search -- Free-text search across incident titles. Reading the table Incident ID is the unique identifier. Title is the AI-generated campaign name. Severity reflects the highest severity among all constituent alerts. Attack Duration is the time from the first alert to the last -- long duration means the threat was active for a while and may have established persistence. Total Alerts shows how many individual alerts were grouped together. How to prioritize Look at Total Alerts first -- a high number means the attacker has hit many systems. Then check Attack Duration -- long duration suggests potential persistence. Work Critical and High severity incidents first. Cases and incidents are independent: Resolving a Case does not close the Incident it belongs to. Incidents are managed separately and stay active until explicitly closed, even after all constituent Cases are resolved. Incident Detail and the Security Incident Report Click any incident row to open the Incident Detail. Investigation & Correlation Shows when the incident was last correlated -- meaning when the AI last checked for new related alerts and added them to this incident. Summary cards Created -- The date and time this incident was first generated, including the exact timestamp. Last Updated -- How long ago the incident was last updated with new information. Linked Alerts -- The total number of individual alerts correlated into this incident. Affected Assets -- The number of unique assets involved across all correlated alerts. Incident Story A plain-language narrative written by the AI describing what happened, why the alerts were grouped together, what the likely attack vector is, and what is currently known or unknown about the campaign. Read this first before reviewing individual alerts or the report -- it gives you the strategic context for the entire incident. Tabs Report -- The primary working tab. Contains the full Security Incident Report including the executive summary, next steps, correlation analysis, and audit trail. Active by default. Timeline -- A chronological log of every event and action in this incident from first detection through each investigation step. Alerts -- The complete list of correlated alerts with their count shown on the tab. Click any alert to open its Alert Detail. IOCs -- All Indicators of Compromise extracted across all constituent alerts, with the count shown on the tab. Signals -- The detection signals and correlation evidence the AI used to group these alerts together. Assets -- The affected assets involved in this incident, with the count shown on the tab. Talk with AI -- Opens the Copilot panel on the right side of the screen, pre-loaded with context from this specific incident. Use it to ask questions about the campaign, get a plain-language summary, or request suggested next steps without leaving the incident page. Resolve -- Marks the incident as resolved and closes it. This action is separate from resolving individual Cases linked to this incident -- resolving an incident does not automatically resolve its Cases, and resolving Cases does not automatically resolve the incident. Both must be closed independently. Report Tab : The Security Incident Report Click the Report tab. This is the most complete view of the campaign. The Security Incident Report is automatically generated for every incident. It provides a structured, formal record of the campaign that can be used for internal review, compliance, or sharing with stakeholders. The report header shows three fields: Report ID -- The unique identifier for this specific report generation. Generated -- The exact date and time the report was generated. Processing Time -- How long the report took to generate. Three buttons sit in the top right: Completed badge -- Confirms the report has finished generating and is ready to read or download. New report -- Regenerates the report using the latest incident data. Use this if new alerts have been added to the incident since the last generation. Download PDF -- Downloads a formatted PDF of the full report suitable for sharing with stakeholders who do not have platform access. Report metadata table A structured table at the top of the report containing reference fields: Document reference -- The unique document ID for this report. Incident identifier -- The incident ID this report belongs to. Primary alert identifier -- The ID of the anchor alert that triggered the incident. Report classification -- The distribution classification of this report. Internal security operations -- restricted distribution means it is intended for internal use only. Generation trigger -- What caused this report to be generated, for example Incident Created. Report prepared (UTC) -- The exact UTC timestamp of when the report was prepared. A usage note below the table explains how to navigate the report: scan At a glance and Your next steps first, then read deeper context in the sections that follow. Full structured data including all IOCs, alerts, and extensions is available in the JSON export and in the incident record in the platform. At a glance A concise summary table of the most important facts about this incident: Severity -- The overall severity level of the incident. Status -- The current state of the incident. Confidence -- The AI's confidence level in its overall assessment of the campaign. Alerts in incident -- The total number of correlated alerts included in this incident. Primary source -- The data source that generated the majority of alerts in this incident. Primary host -- The main internal asset targeted in this campaign. Executive Summary A bullet-point summary of the key findings across the entire incident. Covers what was detected, the volume of activity, threat intelligence results, the severity and confidence level, what automated actions were taken, and the primary IOCs involved. A wrap-up line at the bottom gives the AI's overall assessment and recommended immediate action. Your Next Steps A prioritized list of specific remediation and investigation actions the AI recommends based on the findings. These are ordered by urgency and cover containment, credential management, forensic evidence collection, live triage steps, persistence indicator checks, lateral movement review, and hardening recommendations. Additional recommendations beyond the main list are linked under Appendix -- Full recommendation list at the bottom of this section. Incident Summary A deeper narrative section covering the full context of the incident. Identification and status A structured list of key incident fields: Incident ID -- The unique identifier for this incident. Title -- The AI-generated name describing the campaign. Summary -- A detailed plain-language narrative of what happened, what the alerts showed, what the source IP activity looked like, and what is currently known or unknown about the outcome. Severity -- The overall severity level of the incident. Incident confidence score -- The AI's confidence in its overall assessment of the campaign. Operational status -- The current state of the incident. Alert count -- The total number of alerts correlated into this incident. Organization ID -- The unique identifier of the organization this incident belongs to. Correlation Analysis Explains how and why the AI grouped these alerts into a single incident. Contains the following fields: Why correlated -- The total number of related alerts the AI grouped together and the reason for correlation. Shared hostnames -- The internal hostnames that appear across multiple alerts in this incident. MITRE techniques (sample) -- A sample of the MITRE technique IDs and names identified across the correlated alerts. Tactics (sample) -- A sample of the MITRE tactics observed across the incident. Indicators (IOC) summary -- The total number of unique IOC values found, with examples listed. Shared source IPs (sample) -- The external IP addresses that appear across multiple alerts in this incident. Shared destination IPs (sample) -- The internal IP addresses targeted across multiple alerts. Primary Alert Reference Details of the anchor alert the AI used as the starting point for this incident. Contains the following fields: Alert ID -- The unique identifier of the primary alert. Source -- The data source that generated the primary alert. Severity -- The severity level of the primary alert. Category -- The attack category of the primary alert. Description -- A full narrative of what the primary alert detected, what enrichment showed, and what conclusion the AI reached. Detected at -- The exact UTC timestamp of when the primary alert was generated. Hostname -- The internal host targeted in the primary alert. Source IP -- The external IP address the attack originated from. Destination IP -- The internal IP address that was targeted. Linked Alerts by Type A breakdown of all correlated alerts and events grouped by alert type, showing how many times each alert type fired and its source and severity. This gives a clear picture of the composition of the incident -- which detection rules fired most frequently and at what severity level. Anomaly / UEBA Signals User and Entity Behavior Analytics signals identified during enrichment. These are behavioral anomalies that go beyond standard rule-based detections -- for example, a user successfully authenticating after a high volume of failed attempts, which may indicate a credential-based compromise. Each signal includes a confidence score, the source of the signal, and the contributing factors. Incident and Processing Timeline A timestamped audit trail of every processing step the AI pipeline ran on this incident, in chronological order. Each row shows an event name and its exact UTC timestamp. The events covered include: Incident record created -- When the incident was first generated. Incident record last updated -- When the incident was most recently updated. First alert in incident window -- When the earliest correlated alert was detected. Last alert in incident window -- When the most recent correlated alert was detected. Last correlation run -- When the AI last checked for new related alerts to add to this incident. Primary alert detected (telemetry) -- When the primary anchor alert was first observed at the source. Primary alert received -- When Jutsu/AgentSOC received the primary alert. Enrichment completed -- When the threat intelligence lookups finished for the primary alert. Triage completed -- When the AI finished scoring and classifying the primary alert. Case disposition recorded -- When the routing decision was made and recorded. Report generated -- When the Security Incident Report was generated. This timeline provides full traceability for compliance and post-incident review purposes. Correlated Detections A sample table of the top correlated alerts grouped into this incident, ordered by priority. Identical detections are collapsed to avoid repetition. The header shows how many distinct detection types are represented in the sample and the total number of correlated alerts. A note at the bottom directs you to the full alert list in the incident record or JSON export for complete details. Each row shows: Severity -- The severity level of the detection. Detected (UTC) -- The exact timestamp of the detection. Host -- The internal host targeted. Source IP -- The external IP address involved, if available. Description -- A plain-language description of what was detected. Alert ID -- The unique identifier of the alert, truncated for display. Threat Analysis A narrative section where the AI describes the overall attack pattern observed across the incident. It covers which MITRE techniques were identified, what the behavioral evidence shows, whether any post-exploitation activity was detected, what reputation data returned, and which tactics are confirmed versus suspected based on available telemetry. Impact Assessment The AI's assessment of the confirmed and potential impact of this incident. Covers which accounts and hosts were directly involved, what the blast radius could be across the broader environment, what types of unauthorized activity could have occurred, and what business impact depends on factors not yet confirmed -- such as the privilege level of the affected account or the role of the targeted host. Risk Narrative A concise summary of the overall risk level, the key uncertainties in the investigation, and what immediate actions are required to resolve those uncertainties. This section is designed to be shared with a team lead or manager to convey the urgency and current state of the investigation without requiring them to read the full report. Appendix: Evidence and Traceability Condensed reference fields for audit purposes. The note at the top explains that for long-form triage reasoning, observables, and enrichment tables, the full data is available in the platform or via JSON export. Primary Detection Reference A structured table of the key fields from the anchor alert used to create this incident: Alert ID -- The unique identifier of the primary alert. Source -- The data source that generated it. Severity -- The severity level assigned. Category -- The attack category. Detected (UTC) -- The exact timestamp of detection. Description -- A plain-language description of what was detected. Host -- The hostname and internal IP address of the targeted system. MITRE IDs -- The MITRE technique IDs mapped to this alert. Triage and Enrichment Reference A structured table of the AI's triage and scoring output for the primary alert: Triage category -- The attack category assigned during triage. Triage risk -- The risk score and severity label assigned during triage. Confidence -- The AI's confidence level in its triage verdict. False-positive likelihood -- The AI's assessment of how likely this alert is to be a false positive. Case Disposition Documents the final routing decision the AI made for this incident. Decision Summary A structured table showing the outcome of the AI's triage decision: Is False Positive -- Whether the AI classified this incident as a false positive. Action Taken -- The action the AI took, for example Escalate to Level 2. Decision Time (UTC) -- The exact timestamp of when the routing decision was made. Playbook Execution Shows which AgentSOAR playbook was automatically executed as part of the response, for example Block IP. If no playbook was executed, this section will be empty. Full Recommendation List The complete list of all AI-generated remediation and investigation recommendations for this incident, numbered in priority order. This is the extended version of the Your Next Steps section shown earlier in the report -- it includes all recommendations including any that were truncated in the summary. Audit Trail A single consolidated stream built from the audit logs of the primary alert and every alert linked to this incident. The description at the top explains how the table is constructed: raw audit entries are deduplicated by identical pipeline signatures within the same calendar second, then evenly sampled across the full timeline so that both early and late activity are represented. The summary line shows the total raw entries, the count after deduplication, and how many rows are shown in the table. A note below directs you to the full detail: open each alert's audit history in the platform or use the report JSON export to access the complete audit trail array. The table itself shows four columns: Timestamp (UTC) -- The exact time of the audit event. Name -- The name of the pipeline step or action that occurred. Reason -- A description of what happened at that step and why. Alert -- The Alert ID the audit entry came from. Downloadable pdf The PDF is a formatted, printable version of everything covered in the Report tab -- the same information, structured as a standalone document. It includes the report metadata, At a glance summary, Executive Summary, Your next steps, full Incident summary, Correlation analysis, Primary alert reference, Linked alerts by type, Anomaly / UEBA signals, Incident and processing timeline, Correlated detections, Threat Analysis, Impact Assessment, Risk Narrative, and the full Appendix covering evidence and traceability, triage and enrichment reference, Case disposition, Playbook execution, Full recommendation list, and Audit trail. The footer of each page shows the Report ID, page number, and generation timestamp. A document information note on the final page confirms the report was generated by the AgentSOC incident reporting service and that full structured data is available in the paired JSON artifact and the live incident record in the platform. The PDF is suitable for sharing with stakeholders, storing as a compliance record, or attaching to a post-incident review. It does not update after download -- use New report in the platform to regenerate with the latest data, then download again. Timeline Tab The Timeline tab shows a chronological view of every alert correlated into this incident, displayed as a vertical timeline. Each entry is timestamped on the left and shows a severity badge and the alert description. The first entry marks when the incident started. The primary anchor alert is labeled with a Primary badge alongside its severity badge and contains the full AI verdict narrative for that alert. All subsequent entries show the correlated alerts in order, each with their severity badge and a brief description of what was detected. The color of the dot on the timeline corresponds to the severity of that alert -- making it easy to scan the timeline visually and identify where the highest-severity activity occurred and in what sequence. This tab is useful for understanding the chronological progression of the attack -- when it started, how it developed, and which detections fired at each stage. Alerts Correlation Tab The Alerts tab lists every alert and event correlated into this incident. The header shows the total count split between the primary alert and linked alerts. Each row in the table represents one alert. The columns are: Time -- The date and time the alert was detected. Description -- A plain-language description of what was detected. The primary alert description is shown as a clickable link -- click it to open the full Alert Detail for that alert. Type -- Whether the alert is the Primary anchor alert or a Linked correlated alert. Source -- The data source that generated the alert. Severity -- The severity level assigned to the alert, color-coded for quick scanning. Status -- Whether the alert is the Primary or Linked within this incident. The primary alert row is highlighted in a distinct color to distinguish it from the linked alerts at a glance. Click any alert description to open its full Alert Detail page. IOCs Tab Indicators of Compromise (IOCs) are pieces of evidence that suggest a system has been or is being attacked. They are the observable artifacts extracted from the alerts in this incident -- IP addresses, domains, file hashes, email addresses, and other identifiers that can be used to detect, block, or investigate the threat further. The IOCs tab consolidates all indicators extracted across every correlated alert in this incident into one place. The count shown on the tab reflects the total number of unique IOCs found. IOCs are grouped by type: IP Addresses -- Split into Source (Attacker) IPs and Destination (Victim) IPs. Source IPs are the external addresses the attack originated from. Destination IPs are the internal addresses that were targeted. Malicious Emails -- Email addresses or domains associated with malicious activity detected in this incident. Shown when email-based IOCs are present. Each IOC is displayed as a tag. Use these values when configuring blocks in AgentSOAR, updating firewall rules, or sharing threat intelligence with other teams. Signals Tab The Signals tab shows the detection signals and correlation evidence the AI used to group the alerts in this incident. It is broken into four sections. First Seen & Last Seen Shows the time window of the incident: First Seen -- When the earliest activity in this incident was detected. Last Seen -- When the most recent activity was detected. Duration (temporal pattern) -- The total time span of the incident from first to last detection. Identity Indicators Shows the identity-related observables extracted across all correlated alerts: Hostname -- The internal host or hosts targeted in this incident. Username -- Every username that appeared across the correlated alerts. In a brute-force campaign this list reflects every account the attacker attempted to access. Agent name -- The Wazuh agent name associated with the alerts, if available. OS -- The operating system of the targeted host, if available. Network Indicators Shows the network-level observables extracted across all correlated alerts: Source IP -- All external IP addresses that appeared as attack sources across the incident. Compliance Mapping Maps the activity in this incident to regulatory and threat frameworks: MITRE ATT&CK -- All tactics and technique IDs identified across the correlated alerts, displayed as tags. This gives a complete picture of the attack surface covered by this incident across the MITRE framework. Anomaly-Based Signal Shows any User and Entity Behavior Analytics (UEBA) signals identified during enrichment. These are behavioral anomalies that go beyond standard rule-based detections -- patterns that suggest suspicious activity even when individual events appear normal in isolation. Each signal includes a plain-language description of what was detected, a confidence score, and the source that generated the signal. Confidence & Severity A summary of the AI's overall assessment of this incident: Confidence Score -- How confident the AI is in its overall verdict for this incident. Risk Score -- The overall risk level assigned to this incident. Attack Severity -- The severity classification of the attack, shown as a colored badge. Attack Phase -- The primary MITRE ATT&CK phase the AI identified as the current stage of the attack. Phases -- All MITRE ATT&CK phases observed across the incident, displayed as tags. This shows the full breadth of the attack across the kill chain. Assets Tab The Assets tab lists all assets involved in this incident, both internal hosts and external IP addresses observed across the correlated alerts. Assets are grouped by their inventory status. The Not in Inventory section shows assets that were detected in the incident but do not currently exist in your Assets inventory. The count in the section header shows how many untracked assets were found. Each asset card shows the hostname or IP address and a note confirming it is not in inventory. Click the Add button on any card to add that asset directly to your Assets inventory without leaving the incident. This makes it easy to keep your inventory up to date as new systems are discovered through investigation. --- # Events URL: https://jutsu.ai/docs/operations/events Events are the raw, non-alert log entries received directly from your connected data sources. Every login attempt, authentication failure, network connection,… Go Deeper -- Events The Events Page Events are the raw, non-alert log entries received directly from your connected data sources. Every login attempt, authentication failure, network connection, and system action is recorded here before any AI processing has run on it. The page header shows the total count of events in the current view. The page defaults to Last 24 hours. Events Activity Chart A bar chart showing event volume over time. Each bar represents a time interval. Hover over any bar to see the exact date, time, and event count for that interval. Spikes in volume indicate periods of high activity. Use the chart to identify when activity occurred before narrowing your search with the filters below. Filters All Sources -- Filters events by data source. Options are Wazuh, Google Workspace Email Logs, and Syslog. All Severity -- Filters by the severity level assigned by the originating tool. Search -- Searches across event descriptions, agent names, alert IDs, and source or destination IP addresses. Three-dot menu -- Contains the Clear org SIEM indices option, which permanently wipes all ingested event data for your organization. Only use this if Jutsu support explicitly instructs you to. Events Table Each row represents one raw event. The columns are: Time -- How long ago the event was received. Description -- A plain-language description of the event. Source -- The data source that generated the event. Severity -- The severity level assigned by the originating tool. Status -- The current processing status of the event. Normalized means the event has been processed by the Normalizer agent and is ready for further pipeline steps. Actions -- The three-dot menu on each row contains event-level actions for that specific entry. Events at scale: Never try to review events manually without filtering first. If you are investigating a specific alert, start from the Alert Detail Attack Timeline -- it already shows the relevant events in chronological order. Path: Investigations > Events. Inside an event Two tabs are available: Summary and Raw. Summary Tab Displays the structured fields extracted from this event, organized into three sections. Source Details about the agent and system that generated this event: Agent -- The name of the Wazuh agent that collected this event. Agent ID -- The unique identifier of the agent. Manager -- The Wazuh manager that received the event from the agent. Hostname -- The hostname of the system where the event originated. Program -- The program or service that generated the log entry. Decoder -- The Wazuh decoder used to parse this event. Location -- The log file or journal source the event came from. Rule Details about the Wazuh rule that matched this event: Rule ID -- The unique identifier of the matching rule. Level -- The rule's severity level on the Wazuh scale. Fired Times -- How many times this rule has fired across the dataset. Description -- A plain-language description of what the rule detected. Groups -- The rule group tags assigned to this rule. MITRE ATT&CK -- The MITRE technique IDs, tactics, and technique names mapped to this rule. Network / Identity Network and identity observables extracted from this event: Source -- The source IP address and port the activity originated from. Source User -- The username associated with the activity. Raw Tab Shows the complete, unprocessed JSON payload of this event exactly as it was received from the source. Use this when you need to verify the original log data or when Jutsu support asks for the raw event payload. --- # AgentSOAR URL: https://jutsu.ai/docs/defenses/agentsoar AgentSOAR is the response automation engine built into Jutsu. It lets your team execute defensive actions directly against your connected cloud infrastructure… Stop the Attack -- AgentSOAR AgentSOAR is the response automation engine built into Jutsu. It lets your team execute defensive actions directly against your connected cloud infrastructure -- blocking IPs, isolating hosts, disabling accounts, and controlling server power -- without leaving the platform. The AgentSOAR sidebar contains six sections: Dashboard, Playground, Executions, Containment, Providers, and Inventory. Dashboard-AgentSOAR The Dashboard is the starting point. It shows the current state of the response engine at a glance. Summary cards Playground -- The total number of response actions configured and available. The subtext lists examples of the action types available. Click the card to go directly to the Playground. Cloud providers -- The number of cloud provider credential sets currently connected. The subtext lists which providers are connected. This must be non-zero for any response action to execute. Inventory assets -- The number of cloud assets synced from connected providers. The subtext confirms these are pulled from connected providers. When populated, your team can select assets by name in action forms instead of entering resource IDs manually. Recent Execution Outcomes Live counts of all playbook runs in this workspace. The note below the heading clarifies that Succeeded includes reverted actions. Three counters are shown: Succeeded / Reverted -- Actions that completed successfully or were subsequently reverted. Shown in green. Running -- Actions currently executing. Shown in amber. Failed -- Actions that did not complete successfully. Shown in red. If this number is non-zero, open Executions to read the error details before running anything new. Playground -- The Six Actions Click Playground in the AgentSOAR sub-navigation to see all available response actions. Three filter tabs at the top narrow the list: All (shows every action), Active (shows enabled actions only), and Off (shows disabled actions only). The Actions counter shows the total, active, and off counts. Running an Action Response actions and live infrastructure: All AgentSOAR actions execute immediately against live cloud infrastructure. Each action is logged and can be reversed from the Containment page. Actions require confirmed authorization before execution. Running a Playbook Each action in the Playground is displayed as a card. The card shows the action name, internal ID, a plain-language description of what it does, the cloud providers it supports, an Active badge, an on/off toggle, and a play button. Active badge -- Confirms the action is enabled and available to run. On/off toggle -- Enables or disables the action. When toggled off, the action cannot be executed. Provider tags -- The cloud platforms this action supports, for example AWS, Google Cloud, and Microsoft Azure. Play button -- Click the play button on the right side of the card to open the action configuration form and run the playbook. Inside a playbook When you click the play button on any action card, it opens the full configuration page for that playbook. Page header Shows the action name, its internal ID, the category it belongs to, and a plain-language description of what the action does. Configure The main tab where you fill in the details and run the action. Active by default. The configuration form is split into two sections. The first section identifies the resource being protected: Resource Id (required) -- The identifier of the cloud resource whose subnet you want to protect. Public Ip -- The public IP address of the resource. Private Ip -- The internal IP address of the resource. Hostname -- The hostname of the resource. Display Name -- A label to identify this resource in the execution history. Host Email -- The email address associated with the resource. Host Domain -- The domain of the resource. The second section identifies the attacker: Ip (required) -- The IP address of the attacker to block. The hint below the field specifies this is the attacker's IP, not the protected resource's IP. Reason (required) -- A plain-language explanation of why this block is being applied. This is shown in the execution log and is readable by other operators. Once all required fields are filled, click Run playbook to execute the action. Arguments -- Shows the full parameter schema -- every field name, its data type, and whether it is required. Snippet -- A ready-to-use API call example for running this action programmatically. Configure & Run panel (left) The orange label at the top reads "this action mutates infrastructure." Clicking Run executes the action immediately against your live cloud environment with no additional confirmation step. Recent Runs panel (right) Shows the last 5 executions of this specific action. Each entry shows the target, the outcome -- green for success or reverted, red for failed -- and how long ago it ran. Click View all to open the full execution history in the Executions page. Executions The Executions page shows the full history of every AgentSOAR playbook run in this workspace. The header shows the total count of executions. Each entry includes the console output from the run. The Playground link in the description takes you directly to the Playground to start a new action. Filter tabs Eight tabs narrow the list by execution status: All -- Shows every execution regardless of outcome. Action required -- Executions that need manual intervention to proceed or complete. Running -- Executions currently in progress. Succeeded -- Executions that completed successfully. Failed -- Executions that did not complete. Click any failed entry to read the console output and understand what went wrong. Reverted -- Executions that completed successfully and were subsequently reversed via the Containment page. Revert failed -- Executions where a revert was attempted but did not complete successfully. Expired -- Executions that timed out before completing. Containment The Containment page shows every response action currently in effect across your environment -- all active IP blocks, host isolations, and power changes applied through AgentSOAR. The Active containment header shows the current count of active actions. The description below the header notes that Block IP, Isolate Host, and Power actions currently applied through AgentSOAR are listed here. The Action playbooks link takes you directly to the Playground to enable or configure additional actions. A note on the right side of the header explains what Revert does: it undoes the change in your cloud provider -- unblocking an IP, restoring network connectivity to an isolated host, or restoring the prior power state of a server. Filter tabs Four tabs narrow the list by action type: All types -- Shows all active containment actions regardless of type. Block IP -- Shows only active IP block actions. Isolate Host -- Shows only active host isolation actions. Power -- Shows only active power change actions. When no actions are active, the list is empty. Actions appear here as soon as a playbook is successfully executed from the Playground.Providers and Inventory Providers The Providers page manages the cloud provider credentials that AgentSOAR uses to execute playbooks and sync inventory. All secrets are encrypted at rest using AES-256-GCM. The header shows how many providers are currently saved. Click Add provider to connect a new cloud provider account. Saved providers Lists all connected provider credentials. These are the connections used by playbooks when they execute actions against your cloud infrastructure. The note at the top advises rotating keys in your cloud console rather than here -- values stored here stay encrypted at rest. Each provider entry shows: Provider logo and name -- Identifies the cloud provider and the name given to this credential. Provider type badge -- The cloud platform this credential belongs to, for example GCP or AWS. Health badge -- Shows whether the credential is currently valid and reachable. A green Healthy badge confirms the connection is working. Credential details -- Key metadata about the credential such as authentication mode, project ID, service account email, region, or access key -- depending on the provider type. Added -- How long ago this credential was added. Three-dot menu -- Contains options to edit or delete the credential. Inventory The Inventory page shows all cloud assets synced from your connected providers, grouped by category. It gives you a real-time view of your infrastructure so your team can select assets by name when configuring playbooks instead of looking up resource IDs manually. Provider tabs At the top of the page, tabs let you filter the inventory by provider: All providers -- Shows assets from all connected providers combined. Displays the total count and a Sync all button to refresh all providers at once. Individual provider tabs -- One tab per connected provider, for example Jutsu GCP and Jutsu AWS. Each has its own sync button to refresh that provider's inventory independently. Category filters Below the provider tabs, category buttons filter the asset list by type. All shows every asset across all categories. Additional category buttons appear for each asset type found, for example Cloud instances. Search Search assets by name, ID, IP address, or region. The total count of assets shown is displayed on the right side of the search bar. Asset table Assets are grouped by category. Each category section shows a header with the category name, a description, and the total asset count. The table columns are: Provider -- The cloud provider logo identifying where this asset lives. Name -- The asset name and its unique resource identifier below it. Location -- The region and availability zone the asset is deployed in. Network -- The private and public IP addresses of the asset. Click the copy icon next to either IP to copy it to your clipboard. Status -- The current operational state of the asset, for example Running. Attacks -- The number of attacks detected against this asset in the platform. --- # Assets URL: https://jutsu.ai/docs/defenses/assets Assets is the inventory of every system, server, host, and endpoint Jutsu knows about. It builds automatically from connected data sources and can be supplemen… Know Your Systems -- Assets Assets is the inventory of every system, server, host, and endpoint Jutsu knows about. It builds automatically from connected data sources and can be supplemented manually. A complete inventory improves two things: alert enrichment quality (the AI can tell whether a targeted host is internet-facing or high-value) and response action speed (your team can select assets by name instead of looking up resource IDs). Path: Assets in the left sidebar. Browsing assets Assets display as cards by default. Each card shows the asset name, type badge (Server, Endpoint, Workstation, Cloud Instance, User, Network Device, or Other), IP address, operating system, the responsible person, Wazuh agent groups, environment label, and last seen timestamp. Each card has a three-dot menu for asset-level actions. Click Table view to switch to a compact row layout. Use the search field to find assets by hostname, IP address, location, manager name, or Wazuh group. The All asset types filter dropdown narrows the list to a specific asset category. Adding an asset manually Click Add asset in the top right. Fill in the asset details. Click Save. Syncing from a cloud provider Click Sync from cloud. Jutsu/AgentSOC pulls the latest inventory from all connected providers. The list updates when sync completes. The dropdown arrow on Sync from cloud lets you sync from one specific provider only. Asset discovery: Assets populate from connected integrations automatically. A system that does not appear here has not been discovered through a connected source. Verify the relevant integration is Active under Integrations, or add the asset manually. --- # Copilot URL: https://jutsu.ai/docs/tools/copilot Copilot is Jutsu/AgentSOC's built-in AI assistant. Ask it security questions in plain English: what a specific threat means, what a MITRE technique is, how to… Your AI Partner -- Copilot Copilot is Jutsu/AgentSOC's built-in AI assistant. Ask it security questions in plain English: what a specific threat means, what a MITRE technique is, how to explain the current security posture to leadership, what to investigate next in a case. It understands the context of your environment and can reference your actual alert data when accessed from inside an alert. Two access points: the standalone Copilot page for general questions, and the Talk with AI button inside any Alert Detail for context-specific questions about that specific alert. Path: Copilot in the left sidebar. Starting a conversation Click Copilot in the left sidebar. Click a quick-action button for a pre-filled prompt, or type your own question. Press Enter or click Send. Conversations save automatically. Click the plus button to start a new session. The conversations sidebar on the left lists previous sessions. Each has a rename button and a delete button. Click the sidebar toggle button to collapse or expand it. Quick-action buttons Analyze recent alerts -- Pre-fills a prompt for a summary and analysis of your most recent alert activity. Investigate an IP -- Pre-fills a prompt to look up a specific IP against threat intelligence. Security posture -- Pre-fills a prompt for an overview of your current security status. Useful for management briefings. Generate report -- Pre-fills a prompt to create a narrative summary suitable for a report or briefing. Using Copilot from inside an alert Open any Alert Detail. Click Talk with AI at the top of the page. The Copilot panel opens on the right, loaded with context from that specific alert. Use the pre-built prompts or type your own question. Click the toggle to close. Questions that work well Specific, context-rich questions get better responses than vague ones: 'What does this alert mean in plain English and how serious is it?' 'Is this IP known malicious and should I block it?' 'This brute force is ongoing -- what should I do right now?' 'Summarize the last 7 days of activity in two paragraphs for a management briefing.' 'What is MITRE T1110 and what does it mean that this alert triggered it?' 'Are there patterns across recent alerts suggesting a coordinated campaign?' 'Is the IP 43.160.253.60 known to be malicious?' 'What should I do if this turns out to be ransomware?' 'What does a Confidence score of 42% mean?' Copilot and verification: Copilot provides analysis based on available context. For high-stakes decisions, cross-reference its output against the underlying alert data and threat intelligence results in the platform. --- # Reports URL: https://jutsu.ai/docs/tools/reports Reports generates and manages security digest reports covering your alert and case activity over any selected time window. Use them for weekly team reviews, le… Report What Happened -- Reports Reports generates and manages security digest reports covering your alert and case activity over any selected time window. Use them for weekly team reviews, leadership briefings, compliance records, post-incident summaries, or any situation where a formal document of security activity is needed. Path: Reports in the left sidebar. Summary cards Total Reports -- Total reports generated for your organization across all time. Daily and Weekly Active -- How many automated schedules are enabled. Configure schedules in Organization Settings, not here. Ready Reports -- Reports that finished generating and are available to download now. Generating a report Click Generate Daily Report for the past 24 hours ending at the moment you click. Click Generate Weekly Report for the past 7 days ending at the moment you click. For a specific window, click Custom date range, set exact dates and times, and click Generate. Generation starts immediately. Watch the Status column in the Generated Reports table. When Status shows a green ready badge, click the download icon to save the file. Report time window: Daily and Weekly reports cover the period ending at the moment of generation, not a fixed calendar day or week. For reports covering a specific historical window, use Custom date range. --- # Jutsu API URL: https://jutsu.ai/docs/tools/jutsu-api Everything you do in Data Sources can be done from your own tooling instead. The Jutsu API lets a provisioning script, a CI job, a Terraform local-exec block o… Automate Jutsu — the Jutsu API Everything you do in Data Sources can be done from your own tooling instead. The Jutsu API lets a provisioning script, a CI job, a Terraform local-exec block or an internal portal create and manage assets without anyone opening a browser. One call mints a host, returns its credential, and hands back the install command for that platform. Onboarding fifty servers used to mean fifty trips through the Data Sources dialog. It is now a loop. Path: Organization → API keys in the left sidebar, to mint the credential. The API itself lives at /api/v1/assets on your Jutsu host. What the API covers today: host assets — Linux, macOS, Windows and Docker collectors. Cloud and SaaS integrations such as AWS CloudTrail, Google Cloud Platform and Google Workspace still connect through the console. They will join this surface through the same type field. Reads are not available to console-minted keys yet. Creating, archiving and revoking work today. The two GET endpoints need the workspace:read permission, and the console cannot grant it yet — the create dialog lists it as Unavailable for now. A key you mint today is therefore write-only, and a GET with it answers 403 forbidden naming workspace:read. The read reference below is included so it is ready when that opens up. Create an API key Minting a key is a console action and only a console action. A key can never create another key, and the page is gated on org:manage, so an analyst who opens it would see nothing but errors. Open Organization → API keys in the left sidebar. Click Create key. Give it a Name. Use something you would recognise in an audit log a year from now — "deploy pipeline", not "test". The audit log names the key, never a person, so it is only as readable as the name you choose. Choose an Expiry: Never expires, 30 days, 90 days or 1 year. Never is the default, because most keys run unattended in CI. Select the Permissions the key needs. Manage collectors and integrations is the only one pre-selected, and Read the workspace is greyed out as Unavailable for now — see the table below. Click Create key. Copy the key from the confirmation dialog before closing it. The dialog also shows a ready-to-run example call. [IMAGE1] SHOWN ONCE: Jutsu stores only a hash of the key. The secret exists in that dialog and nowhere else. If you close it without copying, the key cannot be recovered — revoke it and create another. Store it in your secret manager, not in a repository. [IMAGE2] The five permissions Two rules to plan around You cannot grant a permission you do not hold. The scope you can give a key is capped by your own. A permission you lack renders greyed out with the reason shown rather than hidden, so it is clear why it is unavailable. A key is never a route to authority you do not already have. A key cannot mint another key. Key management is deliberately console-only. There is no API endpoint that creates, lists or revokes keys. Managing keys you already have The API keys page lists every key in the workspace with its status badge — Active, Expired or Revoked — its prefix, how many permissions it carries, and four dates: Created, Last used, Expires, and who created it. [IMAGE3] Last used is the column that matters for hygiene. A key that has never been used, or has not been used in months, is a live credential doing no work. Revoke it. To revoke a key, click the bin icon on its row and confirm. Anything using that key stops working within about a minute. Revocation cannot be undone — you would create a new key and update whatever uses it. A key outlives the person who made it. That is the point of a service key: your deploy pipeline keeps running after its author leaves. It also means an offboarding checklist that only removes people leaves their keys running. The creator column shows "a removed user" once the account is gone. The three credentials Three kinds of credential reach Jutsu, and they are not interchangeable. All three are bearer tokens: The credential decides the workspace. There is no tenant header to set, and no way for a key to act on another organization. Keys work on the asset API only. An organization key is accepted under /api/v1/assets and nowhere else. Point it at any other endpoint and it is read as a console session, so it answers 401 invalid or expired token even though the key itself is perfectly valid. A leaked organization key cannot read your alerts or your events. The four endpoints Create a host A 201 response carries three things: the asset, its key, and its install commands. install.install is the one-liner to run on the host. install.verify is the same install with the script's published SHA-256 checked first — prefer it in automation, where nobody is reading the output. Docker differs in two ways: nocurl carries wget and viadocker variants for minimal images, and scriptsha256 is null because the Docker bootstrap is rendered per host, with its hash published at /install-docker.sh.sha256 instead. The install command is built from the host you called. Call api-beta.example.com and the agent is told to report to api-beta.example.com. That is deliberate, because one ingress serves several names — but it means calling the wrong hostname produces a host that ships to the wrong place, with no error. Which source types a host may ship Each platform's allow-list comes from the same catalog the console's tiles use. A 200 from ingest does not confirm delivery. Events outside a host's allow-list are dropped, and so are events sent with a revoked or unknown key — but the ingest endpoint still answers HTTP 200 in both cases. Confirm arrival by checking the host's activity in Assets, never by reading the ingest status code. Read your assets Not usable with a console-minted key yet. Both calls below require workspace:read, which the create dialog cannot currently grant, so today they answer 403 forbidden with requiredpermission: workspace:read. Everything else in this tab works. GET /api/v1/assets lists the estate. Archived rows appear only with ?status=archived. GET /api/v1/assets/:id returns one asset in any status, which is how you confirm that an archive landed. Both return the list item shape, which is not the flat asset object that POST returns. Kind-specific fields sit under a collector or integration object, and a host's real status is the one inside collector: hostplatform is linux, macos, windows, docker, or null when the token names no platform. A health of null means the agent has not reported yet, not that it is unhealthy. Change an asset's status status is active, archived or revoked. What each one does depends on where the asset is now. Notes that save a debugging session Archiving frees a plan slot; restoring re-claims one. A restore can therefore fail with 409 assetlimitreached if the workspace filled up while the asset was archived. Asking for active only succeeds if the asset really becomes active. A host that was revoked before it was archived would come back revoked, so the request is refused with restoresto naming where a restore would actually land, and nothing is changed. Archiving already revokes a host's credential, which is why re-revoking an archived asset is refused rather than pretended. Revoked is final. There is no way back, because the credential is gone. Create a new host instead. Revoked applies to hosts only. An integration answers 409 notacollector whatever its status: its credential lives at the provider and is yours to revoke there. A suspended asset is always an integration. Asking for the status something already has succeeds, so a script that retries converges instead of having to interpret a 409. A key holding no permission that could make the requested change gets a 403 before the asset is looked up at all, so it learns nothing about whether the asset exists. Asset keys — a host that manages itself The apikey in a create response is the host's own jcol… token. It is both what the installed agent ships logs with and what manages that one asset: On the asset API, an asset key reaches only its own asset. It cannot create assets, cannot list them, and cannot touch a sibling; those requests answer 403 assetscopemismatch. That confinement is what makes it safe to leave the key sitting on the host it belongs to. Archiving or revoking an asset with its own key succeeds, and then correctly stops that key from working. A host can retire itself, which is what makes decommissioning scriptable — and it is also why the next point exists. A host that deregisters itself raises a high-severity alert. "Host deregistered itself with its own key" is mapped to Defense Evasion (T1562.001), because a monitored host going dark by its own hand looks exactly like an attacker switching monitoring off. Close the alert if the decommission was planned. The alert is best-effort — it is raised after the change commits, so an interruption at that moment can lose it. The audit log entry is written separately and is the durable record. Errors Every error is a flat JSON object with an error code. 401 and 503 are never used for each other. A 401 means the credential is wrong; a 503 means Jutsu is unavailable. So it is always safe to retry a 503 with the same key, and never useful to retry a 401. A client that re-mints on every failure is reacting to the wrong signal. Rate limits and concurrency About 300 requests per minute per key. Over that is a 429 with a Retry-After header. Asset keys and organization keys have separate budgets. When your plan has an asset ceiling, creates and restores for one workspace are processed one at a time, so the ceiling holds even when a script fires them in parallel. Parallel creates therefore take about as long as sequential ones. A request that waits too long answers 503 assetceilingbusy and can be retried. Plans without a ceiling are not queued. Revoking a key Revoking in the console takes effect immediately on the replica that handled it, and within about a minute everywhere else. If you are cutting off a credential you believe has leaked and you want certainty rather than an estimate, revoke it and then make a call that should now fail. A 401 is your confirmation. What is recorded Every write reaches the workspace audit log naming the credential, not a person: apikey:japiA1b2C3d for an organization key, assetkey:… for an asset key. No individual is blamed for a machine's write. That is also why key names matter. The audit log is only as readable as the names you chose when you minted the keys. --- # Troubleshooting URL: https://jutsu.ai/docs/reference/troubleshooting Why is my alert showing a low confidence score? Troubleshooting Why is my alert showing a low confidence score? Confidence reflects how much evidence the AI had to work with. A low score typically means key data was missing -- for example, the source IP was a private address that cannot be queried in external threat intelligence databases, or endpoint telemetry was not available. Check the Missing Evidence section in the Score Breakdown to see exactly what the AI lacked. Why did the AI close an alert without escalating it to me? The AI automatically closes alerts it classifies as False Positive with sufficient confidence. If you believe an alert was incorrectly closed, open it from the Alerts list, review the AI Verdict and Score Breakdown, and click Reanalyze to re-run the investigation. Why are my incidents not updating with new alerts? The AI runs correlation periodically. New related alerts are added to an existing incident during the next correlation run. Check the Investigation & Correlation section on the Incident Detail page to see when the last correlation ran. I ran a playbook but nothing happened in my cloud environment Go to AgentSOAR > Executions and find the run. Check the console output for errors. The most common causes are missing or expired cloud provider credentials, insufficient permissions on the service account, or an incorrect resource ID in the configuration form. Why is the Geographic Threat Map empty? The map only populates when alerts contain public IP addresses with geolocation data. If most of your alerts involve internal or private IP addresses, the map will show little or no activity. An alert was escalated to a case but no one received a notification Check that the Cases toggle is enabled in Settings > Notifications for the assigned analyst. Also confirm the case is assigned to the correct user -- unassigned cases do not trigger notifications. Why does my risk score stay the same after I add evidence to a case? The risk score on the alert is computed deterministically from the original pipeline evidence and cannot be changed manually. Adding evidence to a case is for your investigation record and audit trail, not for recalculating the score. If you believe the score is wrong, click Reanalyze on the alert to re-run the full investigation. I cannot connect my Google Workspace account Make sure your Google Cloud service account has Domain-Wide Delegation enabled and the correct API scopes granted. The Delegated Admin Email must belong to a Google Workspace administrator with sufficient permissions to access audit logs. If the connection still fails after setup, check the service account JSON for errors and ensure the Customer ID is correct. Why is my MTTD much higher than expected? MTTD measures the time between a threat occurring and an alert being generated. A high MTTD usually means there is a delay between events being generated on your systems and arriving in Jutsu/AgentSOC. Check your SIEM connection under Integrations and compare the Source Time and Ingested At timestamps on recent alerts to identify where the delay is occurring. A team member cannot see alerts or cases Check their role under Organization > Team. Analyst and Member roles have access to alerts and cases. If their role is correct but they still cannot see data, confirm they are logged into the correct organization workspace. --- # Glossary URL: https://jutsu.ai/docs/reference/glossary Key terms used throughout this guide. Glossary Key terms used throughout this guide. Alert. A security event normalized, enriched, scored, and flagged by the AI pipeline. The full pipeline has run before it appears in your queue. AI Processing Pipeline. The seven-step automated chain: Ingest, Normalize, Enrich, Triage, Correlate, Respond, Report. AI Verdict. The plain-language narrative the AI writes for each alert: what it found, why it scored it that way, and what it recommends. Asset. A system, server, host, endpoint, or user that Jutsu/AgentSOC is monitoring or aware of. Attack Timeline. A chronological sequence of events leading to an alert, showing exactly what happened and when. Blast Radius. How many systems or network areas could be affected if a detected threat is real and spreading. Case. A formal human investigation task created when the AI escalates an alert. Always links to exactly one underlying alert. CISA KEV. U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog. A match means real attackers are actively exploiting that vulnerability right now. Confidence. How certain the AI is about its verdict, as a percentage. Below 60% means treat the verdict as a working hypothesis. Contributing Evidence. Factors that increased the AI's confidence -- e.g. three independent TI sources confirming the same IP is malicious. Correlation. Connecting multiple related alerts into one Incident based on shared patterns: attacker, target, or technique. CVE. Common Vulnerabilities and Exposures. A standardized ID for a known software security flaw. Enrichment. Automatically querying external threat intelligence databases to add context to an alert. Escalated to Human. An alert the AI could not resolve with sufficient confidence. Creates a Case for human investigation. Event. A single raw log entry -- one login, one network connection, one file access. Raw material before AI processing. False Positive. An alert that turns out to be benign. The activity was normal, not a threat. File Hash. A unique mathematical fingerprint for a file, used to identify known malware regardless of filename. Global Sync. Toggle in the time range selector that applies your chosen window to every page simultaneously. Incident. A group of related alerts the AI determined belong to the same attack campaign. Incident Report. A structured downloadable document generated automatically for each incident: campaign analysis, executive summary, next steps, audit trail. IOC (Indicator of Compromise). Observable evidence of a potential attack: malicious IPs, suspicious file hashes, known malicious domains. L1/L2/L3 Analyst. Tiered analyst roles. L1: first-line triage. L2: escalated case investigation. L3: complex cases and high-impact action approval. Missing Evidence. Information the AI lacked that would have changed its verdict. Tells you exactly what to look for. MITRE ATT&CK. A public framework cataloguing every tactic (attacker goal) and technique (method) used by real-world attackers. MTTD. Mean Time to Detect. Average time from threat occurrence to alert generation. Lower is better. MTTR. Mean Time to Resolve. Average time from alert detection to case closure. Lower is better. NACL. Network Access Control List. An AWS firewall rule controlling traffic into or out of a subnet. Not Sure. The AI's verdict when it found something suspicious but could not classify it confidently. Requires human judgment. Playground. The response action library in AgentSOAR. Actions execute against live infrastructure -- not a sandbox. Revert. The undo operation in AgentSOAR Containment. Makes the reverse API call to restore the prior state. Risk Score. 0-100 combining how serious the threat appears and how confident the AI is. Higher = more serious and more certain. Security Incident Report. The structured PDF generated for each incident: executive summary, next steps, correlation analysis, audit trail. SIEM. Security Information and Event Management. Collects security logs from your organization. Wazuh is the primary SIEM for Jutsu/AgentSOC. SOAR. Security Orchestration, Automation, and Response. Lets Jutsu/AgentSOC take automated defensive actions. AgentSOAR is the built-in module. True Positive. An alert confirmed to be a real threat. Verdict. AI classification: True Positive, False Positive, or Not Sure. Worker Monitor. Admin-only page in Settings showing health of all seven AI processing workers, with controls to restart stalled workers. --- # Support URL: https://jutsu.ai/docs/reference/support For questions and non-urgent issues, email support@jutsu.ai. To help us respond faster, include: Get Help -- Support How to reach Jutsu For questions and non-urgent issues, email support@jutsu.ai. To help us respond faster, include: Organization name and account email Alert ID or case ID (visible in the URL or at the top of any detail page) What you expected to happen versus what actually happened Date and time of the issue, including your timezone Any error messages, screenshots, or execution IDs --- # AWS Cloudtrail URL: https://jutsu.ai/docs/integrations/aws-cloudtrail Go to app.jutsu.ai and select Integrations in the left navigation. Connect AWS CloudTrail Step 1 - Open Integrations Go to app.jutsu.ai and select Integrations in the left navigation. Step 2 - Select AWS CloudTrail In the Cloud section, select the AWS CloudTrail card. The integration ingests AWS API calls, console sign-ins, and resource changes delivered through CloudTrail log files. Step 3 - Name the integration Enter a name that clearly identifies the AWS account or environment, such as Acme - Production. Keep Cross-account role selected. It is the recommended and currently supported connection method. Access-key onboarding is shown as Coming soon and cannot be selected. Step 4 - Start setup Select Start setup. Jutsu creates a pending integration, a unique external ID, and a secure one-time registration link. The registration link expires after 24 hours. What happens next: Jutsu opens a second phase of the dialog with a Launch stack button. No credentials or resource identifiers need to be copied by hand. Step 5 - Launch the CloudFormation stack Select Launch stack. The AWS CloudFormation console opens in a new browser tab in us-east-1 with the template, stack name, and Jutsu registration values prefilled. Important: Confirm that you are signed in to the intended AWS account. Do not change ExternalId, JutsuAccountId, JutsuAssetId, JutsuRegistrationToken, or JutsuRegisterUrl. Step 6 - Review stack settings and acknowledge IAM Review the resource summary and these optional parameters before creating the stack: At the bottom of the page, select I acknowledge that AWS CloudFormation might create IAM resources. AWS requires this acknowledgement because the template creates IAM roles and policies. Step 7 - Create the stack Select Create stack. CloudFormation begins provisioning the SQS queue, IAM roles, Lambda function, trail discovery, bucket notifications, and automatic registration with Jutsu. Do not close the AWS account or switch regions: You can leave the browser tab open while CloudFormation creates the resources. The stack event list updates as each resource completes. Step 8 - Wait for CREATECOMPLETE Wait until the stack changes from CREATEINPROGRESS to CREATECOMPLETE. A few minutes is normal. The Events tab lists each resource, the current status, and any status reason. If creation fails: For CREATEFAILED or ROLLBACKCOMPLETE, open Events and read the earliest failed resource and its status reason before retrying. Step 9 - Confirm the connection in Jutsu Return to Jutsu. While the setup dialog is open, it checks the registration automatically and changes to Connected. You can also choose Close and finish later; refresh Integrations or Assets after the AWS stack completes. Once connected, events begin streaming shortly. The asset may show Warming up until the first CloudTrail log file arrives. Verify that events are arriving Open Assets and select the AWS CloudTrail asset. During the initial delivery window, the asset may show Warming up. Allow up to about 15 minutes for the first log file. In asset details, check Last event, Source-type breakdown (last 24 h), and 20 most recent events. If multiple trails were discovered, open the asset's Trails action and choose which wired trails Jutsu should ingest. Successfully wired trails are enabled by default. Severity filter: New assets start at Medium and above. Some routine CloudTrail events may be classified below Medium. If the connection is healthy but expected lower-severity activity is missing, review the asset's Severity filter. What healthy looks like Troubleshooting The stack does not reach CREATECOMPLETE Open the CloudFormation Events tab and inspect the earliest failed resource and its status reason. Confirm that your AWS identity can create the IAM roles, Lambda function, SQS queue, S3 notification configuration, and CloudTrail resources in the template. If a stack or queue named jutsu-cloudtrail already exists, inspect it before creating another one. Remove an abandoned stack only when it is safe to delete its resources. The stack is complete, but Jutsu still shows Pending Wait a minute and refresh Integrations or Assets. Check CloudFormation Events for a failure on the JutsuRegister custom resource. The one-time registration link expires after 24 hours. If it expired before registration completed, start a new setup from Jutsu. The asset is Connected, but no events appear Allow up to about 15 minutes for the first CloudTrail delivery. Confirm the source trail is actively logging and delivering files to its S3 bucket. Open the asset's Trails action. The intended trail must be both wired and enabled. A trail bucket owned by another AWS account cannot be auto-wired. Review the asset's Severity filter; the default is Medium and above. When the asset reports that setup is taking longer than expected, use Test connection to verify that Jutsu can assume the role and reach the SQS queue. Security and access No AWS access key or secret is copied into Jutsu. The cross-account role requires a unique external ID and is scoped to the Jutsu SQS queue and the S3 buckets that were successfully wired. The setup Lambda uses broader permissions only while CloudFormation creates or deletes the stack so it can discover trails and manage S3 notification configuration. The one-time registration token is stored by Jutsu only as a cryptographic hash and cannot be reused after successful registration. Pause or disconnect Data-loss warning: If CleanupAutoCreatedTrailOnDelete was left at Yes, deleting the stack also stops and deletes JutsuManagedTrail, empties its managed S3 bucket, and deletes that bucket. Existing customer-owned trails and buckets are not deleted. Related AWS documentation Acknowledging IAM resources in CloudFormation templates Viewing CloudFormation stack events Finding CloudTrail log files in Amazon S3 --- # macOS Host URL: https://jutsu.ai/docs/integrations/macos-host Go to app.jutsu.ai and select Integrations in the left navigation. Open the Data Sources category if it is not already selected. Connect a macOS host Step 1 - Open Integrations Go to app.jutsu.ai and select Integrations in the left navigation. Open the Data Sources category if it is not already selected. Step 2 - Select macOS host Find macOS host in the Endpoint data sources and select the card or its plus button. This single setup enables the macOS audit trail and command-line process telemetry; compliance posture is installed during the same run. Step 3 - Name the collector Enter a human-readable name that identifies the endpoint in your fleet, such as macos-finance-01 or adnan-macbook-pro. The source types are fixed to macos.unified and macos.esf. Jutsu enforces this allowlist at ingest, so the token cannot be used to submit unrelated source types. Step 4 - Create the collector Select Create. Jutsu registers the asset and mints a bearer secret for this Mac. Shown once: The plaintext secret is returned only in the next dialog and cannot be retrieved later. Copy the install command before closing. If the command is exposed, rotate or replace the collector secret before using it. Step 5 - Copy the command and open Terminal In the Collector registered dialog, select Copy command. Optionally expand Verify script before running to download the per-OS script, compare its SHA-256 value, and then execute it. The hash confirms integrity in transit; it is not a code signature. Open Terminal on the Mac you are enrolling. Use a trusted local or remote administrative session, because the copied line contains the collector secret. Command pattern - always paste the exact command copied from your own Jutsu dialog curl -fsSL https://api.jutsu.ai/install.sh | JUTSUTOKEN= sh Step 6 - Run the installer and authorize sudo Paste the copied command and press Return. The bootstrap detects macOS, confirms that the token was created for macOS, downloads the platform installer, and asks to elevate because it installs system services. Wait for the checks to finish. A successful run validates the Vector configuration, starts both LaunchDaemons, verifies the API and ingest endpoints, waits up to 60 seconds for the first event, and confirms osquery enrollment. Password entry: At the sudo prompt, type the password for an administrator account and press Return. Terminal does not display dots or other characters while you type; this is normal. Step 7 - Confirm the asset in Jutsu Return to Jutsu, close the registration dialog, and open Assets. The new macOS asset should appear within about 60 seconds after events and health begin reaching Jutsu. The card shows its name, macos.unified and macos.esf source types, current status, and last-seen time. Select the asset to inspect activity and health details. Step 8 - Resolve a Full Disk Access warning Skip this step when the installer reports EndpointSecurity (macos.esf) source active. If the installer reports that eslogger was denied Full Disk Access: Open Apple menu > System Settings > Privacy & Security > Full Disk Access. Unlock the settings if prompted, select Add, and add the Vector binary path printed by the installer. On Apple silicon this is commonly /opt/jutsu/bin/vector. Add /usr/bin/eslogger as well. TCC can attribute the request to the responsible Vector process, so both paths are required by the Jutsu collector flow. Restart the collector with the command below, then check the log for EndpointSecurity source activity. Restart the collector after changing Full Disk Access sudo launchctl kickstart -k system/ai.jutsu.collector Partial coverage is expected until fixed: macos.unified continues to ship events even when macos.esf cannot start. The asset can therefore appear connected while process-execution coverage is missing. Verify collection and posture In Assets, confirm that the collector shows Connected and that Last seen updates approximately every 30 seconds. Open the asset details and confirm that recent activity is present. On an idle Mac, event delivery can take longer even while health is current. In Terminal, confirm that the Jutsu LaunchDaemon is loaded and inspect the collector log if needed. On macOS 13+, confirm that the terminal install summary or collector log reports macos.esf active after any Full Disk Access change. Open Compliance and allow up to about 1 hour for the first osquery posture checks to appear. What healthy looks like Use these signals together. A current heartbeat confirms the agent is reporting; event and posture data can arrive on different schedules. Severity filter: New assets start at Medium and above. If health is current but expected lower-severity activity is missing, review the asset's Severity filter. Troubleshooting The token is rejected A 401 or 403 during the first token check normally means the secret was rotated, revoked, copied incompletely, or created for another organization. Create or rotate a macOS collector in Jutsu and rerun with the newly shown command. The installer performs this check before installing anything. The asset does not appear within about 60 seconds Confirm that the installer reached Jutsu Agent installed (macOS) and did not stop on a red error line. Run the launchctl and log commands in the verification section. Confirm outbound HTTPS reaches the Jutsu API and /ingest endpoint. If the service is temporarily unreachable, Vector buffers events on disk and drains when connectivity returns. An idle host may not generate an event during the installer's 60-second confirmation window. Current health in Assets is stronger evidence that the service is running. Review the asset Severity filter if health is current but expected informational activity is absent. Vector is not running Inspect /var/log/jutsu-collector.log for a configuration, TLS, permission, or disk error. Confirm that the startup service exists at /Library/LaunchDaemons/ai.jutsu.collector.plist. Make sure /var/lib/vector has enough free storage. Vector can stop when a disk-buffer write cannot be completed safely. Restart with sudo launchctl kickstart -k system/ai.jutsu.collector after correcting the cause. Troubleshooting - macOS-specific cases macos.esf is missing or repeatedly exits Confirm the Mac is running macOS 13 or later and that /usr/bin/eslogger exists. Grant Full Disk Access to both the Vector binary and /usr/bin/eslogger, then restart the collector. If ESF is intentionally unavailable, macos.unified continues collecting. Record the reduced coverage in your endpoint inventory. Installation fails on an Intel Mac Install Homebrew before rerunning. The installer uses Homebrew for Vector on x8664 because the pinned archive is unavailable for that architecture. If Homebrew reports an Xcode or Command Line Tools problem, update those tools and rerun the exact Jutsu command. The installer warns if the Homebrew Vector version differs from the tested pin; capture that warning when opening a support case. Logs work, but Compliance stays unknown osquery requires HTTPS for enroll, configuration, and result logging. A plain HTTP deployment can still receive Vector logs while posture remains unavailable. For an internal CA or TLS-inspecting proxy, rerun the per-OS installer with --tls-ca pointing to a trusted PEM bundle. Run sudo launchctl print system/io.osquery.agent and check that the installer reported osqueryd is running and enrolled. Allow up to about 1 hour for the first scheduled posture results after a successful enrollment. Security and ongoing operations Protect the collector secret Jutsu returns the plaintext collector secret once and stores only its cryptographic hash server-side. The installed host stores the secret in the root-owned Jutsu LaunchDaemon plist and in the osquery enrollment-secret file with restrictive permissions. Do not paste the command into tickets, chat, documentation, screen recordings, or screenshots. Review your shell-history policy because the pasted line contains the secret. If exposure is possible, rotate the secret in Jutsu and redeploy during the selected grace window. Set the grace window to zero for immediate invalidation when containment is more important than continuity. The token is limited to macos.unified and macos.esf at ingest. New collectors also start with a 1,000 EPS limit and a Medium minimum-severity filter. Key local paths Archive and uninstall Archiving and uninstalling are two separate actions. Complete both when removing a Mac from Jutsu. Important: Archiving alone does not stop the local agents. They continue running and retrying until you uninstall them from the Mac. Preview what would be removed - no sudo required curl -fsSL https://api.jutsu.ai/api/v1/public/collector-macos-uninstall.sh | bash -s -- --dry-run Remove the Jutsu collector and osquery curl -fsSL https://api.jutsu.ai/api/v1/public/collector-macos-uninstall.sh | sudo bash Optional - remove Jutsu enrollment but keep a shared or pre-existing osquery installation curl -fsSL https://api.jutsu.ai/api/v1/public/collector-macos-uninstall.sh | sudo bash -s -- --keep-osquery The uninstaller is idempotent: it reports items that are already absent and can be rerun safely. Use the uninstall command shown by the archive dialog when your Jutsu deployment uses a different API base URL. Related documentation Apple - Change Privacy & Security settings on Mac Vector - Buffering model osquery - Remote settings and TLS enrollment --- # Google Cloud Platform URL: https://jutsu.ai/docs/integrations/google-cloud-platform Go to console.cloud.google.com and select the project picker in the Google Cloud header. Connect Google Cloud Platform Step 1 - Open the project selector Go to console.cloud.google.com and select the project picker in the Google Cloud header. Step 2 - Select the project and copy its ID Choose the project whose Cloud Audit Logs you want to protect. After it opens, copy the Project ID from the welcome page. Project ID versus project name: Jutsu validates the lowercase project ID, such as acme-prod-01. A friendly display name such as Acme Production is not accepted in that field. Step 3 - Open Integrations in Jutsu Go to app.jutsu.ai and select Integrations in the left navigation. Open the Data Sources category if it is not already selected. Step 4 - Select Google Cloud Platform In the Cloud section, select the Google Cloud Platform card or its connect icon. This integration pulls Cloud Audit Logs for IAM changes, API calls, and resource activity across services such as Compute Engine, GKE, Cloud Storage, and BigQuery. Step 5 - Enter the connection details Complete the connection form: Step 6 - Start setup Review the project ID and subscription ID, then select Start setup. Jutsu creates a pending asset and prepares a single Cloud Shell command. One-time registration secret: The command contains a 256-bit secret that expires after 24 hours and is consumed on successful registration. Jutsu stores only its cryptographic hash. Do not paste the command into tickets, chat, documentation, or shell history on a shared workstation. Step 7 - Open Cloud Shell and copy the command In the next dialog, select Open Cloud Shell. A new Google Cloud tab opens with the Google Cloud CLI already installed and signed in as your current Google identity. Return to Jutsu and select Copy beside Step 2. Paste only the command generated for your own project. The exact asset ID, Jutsu service account, registration URL, and one-time secret are already filled in. Step 8 - Run the setup script In Cloud Shell, paste the copied command and press Enter. If prompted to authorize Cloud Shell or the Google Cloud CLI, review the account and project, then continue. Wait while the script enables APIs, creates or reuses the named resources, applies the two IAM grants, and registers the asset. Do not close Cloud Shell until the terminal prints Done - head back to Jutsu; the integration flips to Connected automatically. Step 9 - Wait for Done A successful run ends after Registering the integration with Jutsu. The output also confirms the topic, subscription, sink writer grant, and Jutsu subscriber grant. Safe to re-run: If the script stops partway through, fix the reported permission or policy issue and run the same command again while its registration secret is still valid. Step 10 - Confirm the asset in Jutsu Return to Jutsu and open Assets. The Google Cloud project appears as a connected pull integration. It can show Warming up for the first 5-10 minutes while Jutsu waits for the first qualifying event. Select the asset to view connection details, 5-minute, 1-hour, and 24-hour event counts, source-type breakdown, and the 20 most recent events. Verify the connection Open Assets, select the Google Cloud asset, and review Connection details. Confirm the project ID, subscription ID, and Authentication: IAM grant (keyless). Use Test connection. A successful result reads Subscription reachable. The check performs a one-message pull without acknowledging any returned message, so it can be redelivered after the acknowledgement deadline. Allow up to 15 minutes for the first event. A quiet project can show No events yet indefinitely without indicating a fault. Check Source-type breakdown for gcp.audit and review the 20 most recent events after activity arrives. Confirm Last event advances when new qualifying audit activity occurs. Minimum severity: New Google Cloud assets start at Medium and above. Successful routine API calls are often informational in Jutsu and will not appear in analyzed events at this setting. Use the asset's Severity action to choose All events (info) when broader visibility is required. Optional low-impact event test If the project is quiet, temporarily set the asset's minimum severity to All events (info), then create and delete a dedicated test topic. Replace the placeholder with the connected project ID. Generate two Admin Activity events, then restore your preferred severity filter gcloud pubsub topics create jutsu-audit-verification --project= gcloud pubsub topics delete jutsu-audit-verification --project= --quiet Do not use an existing topic: The second command deletes the named test topic. Run it only with the dedicated jutsu-audit-verification name shown above. Coverage and detection behavior The one-click sink matches Cloud Audit Log names across Google Cloud services. Google publishes four audit-log types: Admin Activity, Data Access, System Event, and Policy Denied. High-signal normalization in Jutsu Data Access is optional: Enable Data Access audit logs only for services and permission types that your security program needs. They can materially increase log volume and Google Cloud charges. Alternative setup methods Manual IAM - existing sink and subscription Confirm the existing Logging sink routes Cloud Audit Logs to a Pub/Sub topic and that the sink's writer identity has roles/pubsub.publisher on that topic. Confirm a pull subscription exists and note its project ID and subscription ID. In the Jutsu connection dialog, choose Manual IAM. Enter the integration name, project ID, and subscription ID. Run the displayed gcloud command to grant Jutsu's service account roles/pubsub.subscriber on that subscription. Select Connect, then review the immediate subscription-access test. Service-account key - fallback only Create or reuse a dedicated Google service account and grant it roles/pubsub.subscriber on only the required subscription. Create a JSON key for that service account. Jutsu validates type=serviceaccount plus clientemail, privatekey, and privatekeyid. Choose Key in the connection dialog, paste the JSON, and select Connect. Store and rotate the key according to your credential-management policy. Delete any local downloaded copy after secure transfer. Prefer keyless IAM: Key mode stores the JSON encrypted and uses it only to consume the subscription, but it still creates a long-lived credential. Use One-click or Manual IAM whenever cross-project grants are allowed. Organization-wide coverage The one-click flow creates a project-level sink. Security teams that already operate an aggregated organization sink can route child-project Cloud Audit Logs into a shared topic and subscription, grant Jutsu subscriber access, and connect it with Manual IAM. Validate scope, tenancy, and log volume before using a shared subscription. Troubleshooting The Cloud Shell script reports Permission denied Confirm the active Cloud Shell account and the --project value in the copied command. Ask a project administrator for Service Usage Admin, Logs Configuration Writer, and Pub/Sub Admin, or run the setup with a Project Owner identity. If adding Jutsu's service account is rejected, check domain-restricted sharing and other organization policies that restrict external principals. After permissions are corrected, run the same command again before its 24-hour registration window expires. The script finishes, but Jutsu stays Pending Confirm the terminal reached Registering the integration with Jutsu and the final Done message. Verify that Cloud Shell can reach https://api.jutsu.ai and that a proxy or egress policy did not block the registration callback. Wait one polling interval, then refresh Assets or Integrations. The setup dialog checks status every 5 seconds while open. The registration secret expires after 24 hours. If it expired, start a fresh setup in Jutsu and run the new command. The Google Cloud resource creation is idempotent. The integration is Connected, but no events appear A quiet project is not an error. Admin Activity appears only when configuration changes occur, and most read operations require Data Access logging, which is off by default. Review the asset's Severity filter. Medium and above can intentionally hide routine successful API activity. Use Test connection to verify that Jutsu can consume the subscription. In Google Cloud Log Router, confirm jutsu-audit-sink points to pubsub.googleapis.com/projects/ /topics/jutsu-audit-logs and uses the cloudaudit.googleapis.com filter. On the Pub/Sub topic, confirm the sink writer identity has roles/pubsub.publisher. On the subscription, confirm Jutsu's service account has roles/pubsub.subscriber. If a resource with a Jutsu default name existed before setup, inspect it carefully. The idempotent script reuses existing resources and does not overwrite a pre-existing sink's destination or filter. Troubleshooting - connection test errors Inspect the Google Cloud resources Read-only checks for destination and IAM bindings gcloud logging sinks describe jutsu-audit-sink --project= gcloud pubsub topics get-iam-policy jutsu-audit-logs --project= gcloud pubsub subscriptions get-iam-policy jutsu-audit-sub --project= Security and access Jutsu receives roles/pubsub.subscriber on one subscription. It permits message consumption, not project administration or topic publishing. The Logging sink's Google-managed writer receives roles/pubsub.publisher only on the destination topic. The setup command returns a one-time registration secret. Jutsu stores only its SHA-256 hash; it expires after 24 hours and is consumed on registration. The subscription is the durable cursor. Jutsu acknowledges a message only after ingest accepts it; deterministic event IDs absorb redelivery duplicates. Key-mode credentials are encrypted at rest and written to a temporary, permission-restricted connector file at runtime. Keyless IAM avoids that credential lifecycle. Pause, archive, or remove Check for shared resources: The IAM-mode teardown command assumes the default Jutsu sink and topic names. Before running it, confirm that no other workflow depends on those resources. Deleting a topic or subscription permanently removes that delivery path. Related Google Cloud documentation --- # Windows host URL: https://jutsu.ai/docs/integrations/windows-host Sign in to app.jutsu.ai, then select Integrations in the left sidebar. Connect Windows host Step 1 - Open Integrations Sign in to app.jutsu.ai, then select Integrations in the left sidebar. The Data Sources tab is the connection surface for endpoints, cloud platforms, and SaaS systems. If the Windows tile is visible but not interactive, ask a workspace Admin or Owner to complete the connection. Step 2 - Select Windows host In Data Sources, find the Endpoint section and select the Windows host tile. WHAT IT COLLECTS The Windows collector streams Security and System events. Sysmon events are added automatically when the Sysmon Operational log is present on the host. Step 3 - Register the collector Enter a clear, unique collector name and select Create. Use a name that helps responders identify the device, such as its hostname, environment, or business function. The source types are fixed by the Windows catalog entry and cannot be edited in this flow. Creating the collector reserves one connected-asset slot and creates an asset record immediately. Step 4 - Copy the Quick install command After registration, select Copy command while the Collector registered dialog is still open. SHOWN ONCE The command contains the newly created collector credential and is displayed only in this creation dialog. Copy it before selecting Close. For a normal installation, use the Quick install command exactly as generated. It sets the token in the current shell and starts a child PowerShell process with a process-scoped execution-policy bypass. OPTIONAL INTEGRITY CHECK Expand Verify script before running to compare the downloaded collector script with the SHA256 value shown by Jutsu. Step 5 - Open PowerShell as Administrator On the Windows host, open Start, search for Windows PowerShell, and choose Run as Administrator. Approve the User Account Control prompt if Windows displays one. Use the 64-bit PowerShell executable on a 64-bit host. The installer rejects 32-bit PowerShell on 64-bit Windows. WHY ELEVATION IS REQUIRED The installer writes under Program Files and ProgramData, creates an automatic Windows service, and may install the osquery service. Step 6 - Paste and run the command Paste the copied one-line command into the elevated PowerShell window and press Enter. Keep the same PowerShell window open until the installer returns to the prompt. Do not split or rearrange the generated command; the token assignment must run before the child PowerShell process starts. The bootstrap checks the Windows platform, PowerShell version, administrator rights, token format, and token-to-OS match before handing off to the Windows installer. Step 7 - Wait for installation and validation Allow the installer to download, configure, validate, and start the Windows agents. During a normal run, the console reports these major milestones: Detect the Windows architecture and validate that the token was minted for Windows. Download the published Windows collector script and verify its checksum when available. Install or update the pinned Vector build and write the Jutsu configuration. Validate the configuration, register the JutsuVector service, and set it to start automatically. Verify the Jutsu health and data endpoints, then wait up to 60 seconds for an event to land. Install and restart osqueryd for compliance posture when the Jutsu control plane uses HTTPS. ALLOW TIME The first run may take several minutes because Vector and osquery can be downloaded and installed. Network speed and endpoint security inspection affect the duration. Step 8 - Confirm the installer completed Wait for the success summary and the PowerShell prompt to return. A successful installation should report: Service: JutsuVector is running. Configuration: C:\ProgramData\Jutsu\vector.yaml was written and validated. Connectivity: Jutsu health and ingest endpoints are reachable, or the collector will buffer until they are. Events: The installer either confirms an event reached Jutsu or explains that the host may be idle and to check shortly. Posture: osqueryd is installed and restarted when HTTPS enrollment is available. NORMAL TIMING The final message says the host should appear under Data Sources within about 60 seconds. A quiet host can take longer to show event activity even when the service and token are valid. Verify the connected asset in Jutsu Return to Jutsu and open Assets. Find the collector name you created and confirm that it shows Connected. The asset card should display Windows host and the Windows source-type badges. The relative timestamp should update as health heartbeats arrive. Open Manage from the asset actions to review activity, recent events, health, throughput, buffer usage, and service versions. Post-install verification Use both the Jutsu console and the Windows host to verify that the installation is healthy. A running service proves the agent started; recent activity in Jutsu proves delivery end to end. In Jutsu On the Windows host JutsuVector should report Status Running and StartType Automatic. osqueryd should be Running when posture collection was installed. Log collection can still be connected if osquery was intentionally skipped. The Security log command should return recent events. A quiet log can delay the first visible event in Jutsu. STATUS TIMING Health is reported about every 30 seconds. Jutsu marks a collector offline after more than 90 seconds without a heartbeat; short gaps can appear as idle before becoming inactive. Troubleshooting Start with the exact message printed in the elevated PowerShell window, then use the checks below. SAFE RERUN The Windows installer supports rerunning on an existing host. It replaces the managed JutsuVector service and configuration, validates the new setup, and preserves the final automatic service state. Day-2 operations Manage the collector Health and activity: Open the Windows asset in Assets to review the latest heartbeat, event counts, buffer usage, dropped events, CPU load, memory, and versions. Token rotation: Rotate the collector credential from its management actions. The previous credential can remain valid during the selected grace window while the new command is redeployed. Archive and uninstall: Archive the asset in Jutsu to stop accepting new ingest and free the plan slot, then run the Windows uninstaller from an elevated PowerShell window to remove the local JutsuVector service, configuration, buffer, and Jutsu-managed posture agent. Completion checklist The Windows host collector has a recognizable name. The generated command was run in an elevated 64-bit PowerShell window. The installer returned to the prompt without a fatal error. Get-Service JutsuVector shows Running. The Windows asset shows Connected in Jutsu. Security and System events are visible; Sysmon events are visible when Sysmon is installed. Health timestamps continue to update and the asset reports Healthy. osquery posture is enrolled when endpoint compliance monitoring is required. COMPLETE The Windows host is integrated when its asset remains Connected and current Windows events are visible in Jutsu. ---