About
A security engineer who builds the thing he secures.
THE FOUNDER
I'm Sayo. I started Atypical Tech because I kept watching teams hand real power to AI agents and just hope.
I didn't come to security from security. I came from building: fourteen years of it, first as a full-stack engineer shipping consumer, media, and platform products, then as the person responsible for making software safe to ship at all.
I learned to secure software the only way that sticks, by building it first.
Somewhere along the way I stopped writing features and started writing the guardrails: AppSec programs, DevSecOps pipelines, code-signing and PKI, the security plumbing that lets a team move fast without shipping its next breach. At an electric vehicle maker, that meant moving firmware signing off shared keys and onto a cloud signing service, and giving vehicles identities of their own. I earned my CISSP. Then AI changed what “fast” even means, and I went looking for the new edge.
I found it on an AppSec team at a large enterprise. We turned on a commercial code scanner and it surfaced more vulnerabilities than anyone could ever work through, a backlog no one could clear, and an engineering org too buried to touch them. So I built an AI agent to triage them: read each finding, gather the context I would, score the real risk. It used judgment the way I would. That's what made it an agent, not a script.
The first findings it worked made the case: most of them were noise, and the real ones finally stood out. Today it works through every project in the scanner on a schedule, and a finding becomes a ticket only after it's confirmed.
But the volume it cleared isn't what I'm proud of. When every ticket engineers get from security is a confirmed one, a ticket means something again. Security stops being the team that cried wolf.
Here's why that story is the whole company. I didn't just build an agent. I built a safe one, and that meant thinking like an attacker about what an agent actually is: a program that reads untrusted input and then acts. Every finding it ingested was untrusted input. A poisoned one could try to talk the agent into acting outside its job: prompt injection turning it into a confused deputy, using its own access to do the attacker's work.
So I never handed it mine. It ran in a scoped container with a scoped toolkit, under its own identity and its own credentials, built for exactly one job. A hijacked call could reach only what the agent itself could. The blast radius was the agent's access, not mine, and every action traced back to the agent, not to me. Every verdict went into a decision log, so any call it made could be checked after the fact.
An agent needs its own identity for the same reason a person does, so you always know who did what.
So when I tell you I'll secure your agent (scope it, give it its own identity, put boundaries and observability around it), I'm not reading from a framework. I'm describing what I already built. I built a safe agent before I offered to secure anyone else's.
WHAT I'VE SHIPPED
The patterns I'll bring to your team come from systems I've built and run. A few of them:
- An AI triage agent at a large enterprise. It cleared most of a scanner backlog as not exploitable or false positives, surfaced the findings that were real, and keeps a reviewable log of every decision it makes.
- Security for a live AI platform. Guardrails defined in code across multiple cloud regions, a logging and redaction policy, zero data retention for every model in use, and prompt-injection testing that mapped exactly which attacks the filter misses.
- An LLM inside a CI gate. A step that checks blocked dependency licenses against a written rubric and posts a structured verdict on the pull request, authenticating with short-lived OIDC credentials instead of stored secrets.
- A pen test of an LLM product. I validated the findings, traced eleven of them to two root causes, and led the remediation walkthrough with product and engineering.
- A vulnerability management program from zero. Charter, governance, and a four-phase roadmap, published four months after I walked in the door.
- Machine identity before agents. A cloud code-signing service and certificate vending for vehicles, anchored by an offline root CA, at an electric vehicle maker.
- Supply-chain response. Exposure checks through the npm, React2Shell, Trivy, LiteLLM, and axios compromises, and scanner images pinned by digest after a security scanner itself was compromised.
HOW WE OPERATE
We operate what we advise, and I'll be honest about what that actually means, because the absolute version of that line is marketing, not engineering.
I hold Atypical's own infrastructure to the same patterns I'd design for a client (scoped identities, boundaries, observability), but I apply them as they make sense for where we actually are, not wholesale. Security is point-in-time: what's sound today gets revisited as the stack changes. Our setup evolves the same way a client's will, because that's how real systems work.
Security is point-in-time: not a box you check once, but a call you keep making.
So I won't prescribe anything wholesale, because prescribing wholesale isn't sound engineering. What I bring is judgment from running these systems myself: when a pattern earns its keep, when it's overkill, and what it actually costs to live with. That's the difference between advice from the sidelines and advice from someone carrying the same tradeoffs you are.
Running these systems also taught me what the frameworks skip: the failures around an agent tend to be quiet. Early on, a few of mine went on longer than they should have before I caught them. The agent wasn't hiding anything. Nothing was watching closely enough. Now monitoring is the first thing I build.
A system that fails quietly looks exactly like one that's working.
Guardrails can fail the same way: deployed and marked ready, with nothing actually running through them. That's why observability isn't the last phase of my engagements. It's how I know the controls are real.
A control that looks enforced and enforces nothing is worse than a missing one.
PHILOSOPHY
Ten principles guide every engagement, and they're the foundation of our ROBOT Framework, the methodology for designing safe, predictable, auditable agentic systems.
Constraints aren't the opposite of capability. They're the permission to use it.
Outcome First
Start with the result you need. Work backward to the simplest path that gets you there. Technology is a means, not an end.
Context Second
Once the outcome is clear, gather context. Understand constraints, dependencies, and the human systems around the technical ones.
Constraints Before Capabilities
Define what automation should never do before expanding what it can do. Safety comes from clear boundaries, not clever features.
Remove, Reduce, Reveal
First remove unnecessary steps entirely. Then reduce complexity in what remains. Finally, reveal the clearer signals that emerge.
Safety Before Autonomy
Earn trust through safe, incremental automation before expanding scope. Speed without safety isn't speed. It's just risk.
Low-Risk Wins First
Start small. Start in non-production. Build trust through quick, obvious wins before expanding scope. Credibility is earned incrementally.
In practice: my rollout rule for any new security gate is advisory first, then soft enforcement, then hard. Developers learn the rule before it ever blocks them.
Human-Centered AI
Automation should augment human judgment, not replace it. Keep humans in the loop where it matters. Remove them only from the noise.
Transparent Decision-Making
Automated systems must explain how they reach conclusions. Audit trails aren't optional. Humans should never just trust a black box.
In practice: every verdict my triage agent reaches is written to a decision log, and samples get re-derived blind to check the agent's work.
Intelligence Over Complexity
Solutions should simplify workflows, not add new tooling burdens. If automation creates more overhead than it removes, it's not intelligent.
Never Break Availability
Automation that threatens uptime isn't worth having. Safety and reliability are non-negotiable.
In practice: when code scanning broke right after I shipped a rule pack, I pulled the pack first and investigated after.
WHO WE WORK WITH
We build for technical leaders putting AI agents into production: the people who feel the pain first.
Engineering & platform leaders
Shipping agentic features and accountable when they misbehave.
Hands-on technical founders
Putting an AI agent in the critical path of the product.
AppSec & security teams
That want agent-security depth on tap, not another full-time role to fill.
Teams without dedicated security
That need senior expertise a hire-stage team can't yet justify hiring full-time.
In general: anyone giving an AI real power who isn't willing to just hope it behaves.
I built my first safe agent because the alternative was hoping. If your agents already have the keys, let's make sure that's actually safe.