Detection Engineering & AI Security

Overview

We build the detections that catch real attacks, and set up AI agents that speed up your security team’s routine work. When other teams start using AI agents, we build the guardrails those agents run inside, with the access limits and logging your security team needs. Everything is delivered as code you own.

Sentinel Detection Engineering

We design, deploy, and tune Microsoft Sentinel so it actually detects the attacks that matter, and we deliver the detections as code, KQL analytics and hunting rules, deployed as Terraform, that your team owns. Not a dashboard we watch for you, a detection capability you run.

The Process

  1. Define what you need to detect

    We start from the threats and attack paths relevant to your environment, the same ones our red team would use, and define the detection use cases that matter. Not a generic rule pack.

  2. Design the data and architecture

    We decide which log sources you actually need, size ingestion for cost, and design the Sentinel workspace and connectors. Cost is controlled before it runs away, not after.

  3. Build detections as code

    We write and version the analytics rules and hunting queries in KQL, deployed as Terraform, with response playbooks as Logic Apps, all version-controlled in a repository, mapped to MITRE ATT&CK.

  4. Tune out the noise

    We reduce false positives, tune thresholds, and validate detections against real attack techniques, so your team sees signal instead of alert fatigue.

  5. Hand over and iterate

    Your team owns the detection content and can maintain it without us. As new threats and log sources appear, we extend the coverage.

The Outcomes

  • A Sentinel deployment tuned to detect the attacks that actually matter to you

  • Detection content as code your team owns and can maintain

  • Ingestion sized and governed for cost, not runaway bills

  • Fewer false positives, and coverage you can map to MITRE ATT&CK

AI Guardrail Engineering

Your teams already use AI agents, from coding agents in your pipelines to Copilot agents in Microsoft 365 and more. We build the guardrails those agents run inside, so each agent gets only the access it needs and every action is logged. This is harness engineering, owned by security. Not a policy document nobody reads, but controls built into how your agents run.

The Process

  1. Find agents

    We find the AI agents and coding tools your teams use, including the ones nobody registered. For each one, we note who owns it and what data and systems it can reach.

  2. Set the rules

    We agree with you what each type of agent may do. An agent can read only, suggest changes, or act with human approval, depending on the risk of what it touches.

  3. Build the guardrails

    We give each agent its own identity with an owner, minimal access and an expiry date. Secrets stay out of prompts, coding agents run in a sandbox, and text from issues, tickets or emails is treated as data, not instructions.

  4. Log and detect

    Agent activity goes into your SIEM, with detections for misuse, such as an agent reading secrets it doesn’t need or sending data somewhere new.

  5. Test and keep current

    We try to make your agents leak data or act outside their limits, and fix what gets through. As your teams add new agents, a monthly plan keeps the guardrails current.

The Outcomes

  • An inventory of AI agents in use, who owns it and what it can reach

  • Clear rules for what each agent may do

  • Guardrails delivered as code your team owns

  • Agent activity logged and monitored in your SIEM

Security Agent Engineering

We build AI agents across security team's daily work, from detection and vulnerability triage to cloud fixes, access reviews and compliance evidence. The agents learn your environment, use your tools with read-only access by default, test their own output, and wait for your approval before anything ships. This is harness engineering for security teams. Not a generic chatbot, but agents that know your environment and show their work.

The Process

  1. Pick the work

    We identify repeated tasks with your team, for example triaging scanner findings, writing a detection from a threat report, drafting a Terraform fix for a cloud finding, or answering a customer security questionnaire. We measure how long they take today, so the gain is proven, not guessed.

  2. Build the context

    We write down what the agents need to know about your environment, such as your systems, owners, naming rules, risk priorities and past incidents. The agents stop guessing and work like someone who knows your company.

  3. Connect the tools

    We connect the agents to systems, with read-only access by default. Secrets stay out of their context, and text from tickets or reports is treated as data, not instructions.

  4. Build skills and checks

    We turn each task into a step-by-step skill, with tests the agent runs on its own output. A detection has to fire on sample attack data, a Terraform fix has to pass a plan, and a questionnaire answer has to point to real evidence before anyone sees it. Nothing ships without your team’s approval.

  5. Hand over and improve

    Your team runs the agents on its own. Every agent mistake becomes a new rule or test, so the harness gets better at your environment over time. If you want us to keep going, a monthly plan covers new skills, fixes and changes for new models.

The Outcomes

  • Routine security work done faster, with before and after numbers

  • AI agents that know your environment, not generic ones

  • Every output tested and approved by your team before it ships