Viacursor / projects & research by Laremy Padilla

Viacursor

Network security tools I build, and the research questions I can't put down.

I'm a network security engineer who builds the tools I wish existed — KEVLAR for vulnerability posture, reconfigd for configuration posture — and writes about AI security, MCP architecture, and how LLMs get manipulated. Engineer-built, framework-grounded, no vendor pitch.

see what I build → github.com/networkitout →
01 / what I build

Two projects, one design system, two audiences.

Each project covers a distinct axis of network security posture. They share infrastructure, design language, and operating principles — but speak to different people in different rooms with different jobs to do. Both started the same way: a gap I kept running into at work, and no tool I wanted to buy.

KEVLAR
in production
vulnerability posture · executive-readable

A vulnerability correlation tool I built and run in production. It ingests asset inventory from CrowdStrike, Entra, LogicMonitor, and Meraki, enriches it against the CISA Known Exploited Vulnerabilities catalog, and surfaces what an executive actually needs to see — without the noise of every CVE in existence.

  • CISA KEV detection across managed assets
  • Trend data and resolution tracking over time
  • Connector ecosystem: CrowdStrike, Entra, LogicMonitor, Meraki, and growing
  • Built for the boardroom, not the SOC
follow along on GitHub →
reconfigd
pre-release
configuration posture · engineer-readable

A daemon I'm building that ingests network device configurations, audits them against security frameworks (NIST, CIS, STIG), and ships ready-to-paste remediations with the context engineers actually need to apply them.

  • Multi-vendor: Cisco, Palo Alto, Fortinet, Juniper, Meraki
  • Cut-and-paste remediations with inline explanations
  • Framework citations on every finding (no "best practice" hand-waving)
  • Built for the engineer, not the auditor
visit reconfigd.com →
02 / what I'm researching

The questions that follow me home from work.

The tooling above scratches an operational itch. The research below scratches a different one: how AI systems fail, how they get manipulated, and what the security architecture around them should actually look like. Everything here is independent work — written up, tested, and shared as it matures.

/ 01
MCP Reference Monitor

Applying Anderson's Reference Monitor formalism — the 1972 foundation of trusted computing — to Model Context Protocol server validation. If MCP servers are going to sit between LLMs and everything they touch, the mediation layer deserves the same rigor we demanded of operating system kernels.

mcp reference-monitor trusted-computing ai-security
/ 02
The Locutus Attack

AI safety research documenting session-based manipulation vulnerabilities in large language models — how sustained conversational pressure can shift a model's behavior in ways single-prompt jailbreak testing never catches.

llm-security manipulation ai-safety
/ 03
CTEM field guide

An educational resource on Continuous Threat Exposure Management for security practitioners — what the framework actually asks of a program, stripped of the vendor marketing that usually surrounds it.

ctem exposure-mgmt education
/ 04
AI-assisted security engineering

Working notes on integrating LLM-assisted development into security engineering without the failure modes — confident model errors, context drift, lost architectural ownership. Drawn from building every project on this page that way.

ai-engineering claude verification
03 / how I work

The principles that govern everything I ship.

These apply equally to the projects, the research, and the way I write a single line of remediation. When a decision feels uncertain, I come back here.

/ 01
Engineer-first

I build for the people who'll use it, not for a pitch deck. If it doesn't survive contact with a real network, it isn't done.

/ 02
Running software over write-ups

Ideas earn their keep by shipping. Every research question here ends up as something you can run, read, or reproduce — not just a thread of opinions.

/ 03
Outcome-oriented

Projects are named after what they make true. KEVLAR for protection. reconfigd for configurations brought into compliance.

/ 04
Framework-grounded

Every recommendation cites a specific control. NIST 800-53. CIS. STIG. No "industry best practice" hand-waving.

/ 05
Quietly confident

Confidence comes from specificity, not enthusiasm. Name the exact control, the exact remediation, the exact blast radius.

04 / find me

Curious about the projects or the research?

I'd rather have a real conversation than a form submission. Find me on LinkedIn, follow the work on GitHub, or just poke around reconfigd.com — I'm always happy to talk shop with people who care about this stuff.

linkedin.com/in/laremy → github.com/networkitout →