An agent writes code only as securely as the context it receives. Give it flawed context, and it will confidently build the right feature insecurely. Most teams assume that flawed means not enough.
The common instinct is to give agents more context: threat-modeling skills, security checklists, policy files committed to the repo so the guidance is always in reach. It backfires. Faced with too much context, the agent compresses it until the actionable knowledge is summarized away, leaving the agent unable to secure the task at hand. The result is that your organization invested effort, learnings, and countless tokens, and the agent still misses critical threats or flags ones that don’t apply
What decides whether the code is secure isn’t how much guidance the agent can see. It’s whether that guidance is scoped to the task in front of it and grounded in how your system is actually built.
Today we’re releasing Kura, Adaptive Security Context for coding agents.
Kura succeeds at solving this because of the engine that sits behind it. Clover already maintains a living threat model of your application, one that keeps pace as your architecture and code change.
Kura draws on that model in real time: for every task an agent takes on, it pulls only the threats and countermeasures relevant to that task and applies them as the plan and the code take shape.
Check out the full press release here.
What Kura does
For every task an agent picks up, Kura hands it the security requirements and threats counter measures for that feature, and nothing else.
- Scoped to the task – Kura selects only the security requirements and threats countermeasures that apply to the feature being built, rather than loading everything in the repo.
- Applied as the code is written – Kura supplies the context while the agent plans and writes, so the requirements are in place before the code exists, not raised in a later review.
- Removes redundant requirements – When a control is already enforced elsewhere in the stack, Kura leaves it out. That keeps the generated code smaller and uses fewer tokens.
- Traceable to the continuous threat model – Each requirement links to a named entry in your threat model rather than a generic rule, so a reviewer can see where it came from.
Real-life example: the @mention directory leak
To see what task-scoped context actually catches, we tried it on Plane, the open source project management tool. We added a realistic feature, an External Collaborator Portal that lets outside users comment on and edit specific threads, and we planted one flaw inside it.
Collaborators can @mention internal team members, and the picker reuses Plane’s normal member autocomplete. The catch is that the autocomplete is scoped to the entire workspace. So an outside collaborator can type a single letter and page through the whole internal directory, names and emails and all. It’s broken access control, straight out of the OWASP Top 10, and it’s hiding inside a requirement that reads like a perfectly normal product decision.
We handed the same task to three setups:
- an agent with generic security context,
- the same agent using a model provider’s own security skill
- agent running on Kura.
The agent’s original plan
The same plan after Kura
Kura turned that into six requirements the agent had to satisfy:
- Scope restriction
- Minimum query length
- Rate limiting
- Minimal data exposure
- Audit logging
- Admin kill switch
The list itself is ordinary OWASP hygiene. The point is that no one wrote it for this feature. Kura derived it from your threat model, recognized that a workspace-scoped picker on an external portal was broken access control, and attached exactly these controls to exactly this task.
What Kura changes in production
For the past several months, Kura has been running in production across our enterprise customers’ Agentic SDLCs, as well as our own. For the first time, those teams can see how their agents build: what each change decided, where it introduced risk, and how Kura addressed it, all in one place and in real time, and the security bar holds no matter which agent writes the code, whether it is Claude, Codex, or whatever comes next. Seeing customers rely on Kura in production was the strongest validation, but we wanted to test it on a less forgiving audience too: our own engineers. So we turned it on quietly across our Agentic SDLC and did not tell them, because we wanted a clean answer to one question: would anyone notice? If Kura slowed a session down or buried engineers in requirements that did not matter, we would hear about it immediately.
Three months in, we haven’t. The overhead comes to about 22 seconds a session, and Kura quietly took work off the pile: it caught controls our Claude and Codex instances proposed that were already handled elsewhere, like rate limiting the API gateway already enforced, and dropped them before anyone wrote a line. The bigger change was the rework. A feature that looks done but hides a security problem has to be rebuilt from scratch, and Kura catches the flaw before the code exists, so that rework never starts. Over the same period, feature rewrites caused by security issues fell 83%.
