Agentic Security & Compliance Platform

Repository and security analysis operates on large, inconsistent code and context. Reasoning spans multiple stages, security policy has to be evaluated against that context, and a finding only matters if it comes with actionable remediation. And the core reasoner — an LLM — is probabilistic: its output can’t be blindly trusted, so the system has to make it trustworthy through engineering.

The platform was a team effort — I wasn’t its sole architect, and this isn’t the whole security program. My engineering contribution spanned:

• Repository / context ingestion & shaping — pulling code and dependency context from GitHub repositories and structuring it so downstream analysis works from relevant material.
• Multi-step agent workflows — orchestrating security analysis in controlled stages rather than one-shot prompts.
• Deterministic policy / guardrail evaluation — working on deterministic checks that bound and validate agent findings.
• Structured findings & remediation — developing machine-readable finding structures with risk / impact context and actionable remediation guidance.
• Tool / repository integration — embedding analysis in source-control workflows where the code is written.
• Observability & failure handling — keeping agent runs observable while respecting the system’s security boundaries.

The system is internal security / compliance tooling, built in Python; analysis happens where the code lives, not in a detached console. Conceptually, a run moves through these stages:

• Context shaping. Repository content routinely exceeds a useful model context. The relevant material — which files, which dependencies, which symbols — has to be selected and structured before any analysis.
• Multi-step orchestration. Complex security analysis is decomposed into controlled stages instead of one giant prompt; each stage produces structured output that can be validated before the next stage.
• Structured outputs. Downstream consumers — tooling and people — need predictable, machine-readable results rather than arbitrary prose, so findings are emitted as structures.
• Deterministic controls. Policy and security decisions can’t rest on probabilistic model output alone; deterministic checks bound what an agent may conclude.
• Risk / impact analysis. Detection is the easy part; a finding without blast-radius / impact context and prioritization is hard to act on.
• Remediation. The output is meant to help developers act — concrete next steps — rather than simply report.

• Malformed structured output is validated against the expected structure before use; malformed results are flagged, not silently accepted.
• Incomplete context is a first-class case: workflow steps degrade gracefully instead of compounding errors.
• Tool, repository, and agent-step failures stay observable — failure modes are logged rather than guessed.
• Execution is kept bounded: enough autonomy to be useful, enough constraint to be safe.
• Deterministic guardrail evaluation doubles as a reliability control: it puts a predictable boundary on probabilistic output.

Two categories: controls I worked on, and design considerations the architecture has to account for.

• Repeatable, structured analysis of the same class of problem.
• Actionable remediation output instead of raw reports.
• Controlled multi-step workflows: autonomy with constraint.
• Deterministic validation around probabilistic analysis.

No quantitative business impact is reported in this case study; the engineering outcomes are what this covers.

The hard part of agentic systems is the surrounding engineering: context shaping, workflow decomposition, guardrail design, and output structuring. That is the same discipline as distributed-systems work, applied to security tooling.