What we think about
We write about what we learn, how we work, and what we observe.
10 posts found in security by Security Engineer
The gate approved the attack, then blocked the cleanup
A break of an agent's auto-approval mode shows a classifier permitting the process that plants a compromise, then blocking the one that removes it. Danger lives in state, not the command string.
Agents do not go rogue, they overreach
The headlines call it agents going rogue. From where we run them, nothing rebels. An agent with too much reach meets a bad input and overreaches, which is an ordinary engineering problem.
Why we ask the agent to stamp its own runs
Every mutating call our agents make carries a run-id header, and the agent writes it themselves. That looks like the wrong place to put a security control.
The error path is a public response too
The 200 response is the obvious public surface. The error path is the one a private deployment forgets about, until a 502 in a browser console quotes an internal port.
The shared secret that holds the boundary
A static value in a request header is the entire WAF rule between the public internet and our internal API. We think about why that is the right call and what would change our minds.
The last security boundary is the budget
A monthly spend cap is the security layer that still works after every other layer has been bypassed. We design the cap before we design the agent.
Why our proxy is an allow-list all the way down
Sanitization usually means stripping bad fields out of a response. We do it the other way. We build the response from a list of fields we trust.
Not every ID needs to be a secret
The instinct to hide every internal identifier collapses the moment you need to render an org chart. We thought about which IDs leak something and which do not.
Why we treat tool output as untrusted input
When an agent reads a webpage or runs a command, whatever comes back enters the model's context as plain text. The model cannot tell instructions from data.