AI features add new ways for things to go wrong: a prompt that leaks, a tool that can do too much, an answer nobody can trace. We review, test and build the controls that keep a person in charge.
“We are shipping an AI feature and nobody has reviewed it.”
A security review of the feature and the application around it: inputs, outputs, tools, secrets and data paths.
“How do we know the AI is giving good answers?”
An evaluation set built from your real cases, run before launch and after every change.
“If it does something wrong, can we find out why?”
Audit trails: what was asked, what the system did, which tool it used and who approved it.
“Can the agent do more than it should?”
Least-privilege access per tool and per role, with approval on anything that cannot be undone.
“Our keys are sitting in config files.”
Secrets moved into a vault, scoped, rotated and kept out of prompts and logs.
Six pieces of work. You can take one, or all of them as part of a build.
A threat model and review of prompts, tools, data flows, authentication and dependencies. Findings are ranked and fixes proposed.
Test sets drawn from your cases, scored for accuracy and for correct refusal, and rerun on every change.
Structured logs of each request, tool call and decision, retained under rules you set.
Approval queues for actions that spend money, send messages or change records, each with a named owner.
Narrow permissions per tool, per agent and per user, so a mistake or a misuse has a small reach.
Vaulted credentials, scoped tokens, rotation and redaction, so secrets do not travel in prompts or logs.
Yes. Controls only get used when they sit inside your existing flow, so we build them into it.
We work from access you grant, scoped to the systems in scope. Nothing outside that scope is touched.
Reviews and controls follow the system wherever it runs. What changes is who owns each risk.
Fits, with limits
Data stays on the machine, which removes the risk of transit. Logging and approval need a plan, because there is no central server to hold them.
Fits
You own patching, network rules and log retention. We review the deployment and the model-serving layer with you.
Fits
Identity, keys and network segmentation live in your account. We review the configuration as well as the code.
Fits
The boundary between local and cloud is the main risk. We check what crosses it and that each crossing is logged.
Fits
Provider terms, retention settings and shared-responsibility limits matter most. We read them with you and record what is assumed.
For technical readers: what we choose from. The choice is made per system, from your data, your constraints and your workload.
We name clients only with their written permission. These are systems we run, and the controls are part of how they work.
Klyntar, the security layer inside Daena: a scan workflow, evidence checkpoints and a gate that rejects a serious finding with no evidence chain.
Beta, with access on request at daena.mas-ai.co. It is the reference architecture we draw on for governed agent builds.
Read the case study
An encrypted vault, per-tool policy, an approval gate and an audit log for AI access to your tools.
Open sourceRead the case studyDeterministic checks decide when work is done, and every verdict is logged.
System we operateRead the case studyResearch: bounded authority, budget stops and signed receipts that anyone can verify offline.
R&DRead the case studyThe feature and what surrounds it: how input reaches the model, what the model can call, what it can return, where secrets and data live, and how access is checked. AI-specific issues such as prompt injection sit alongside ordinary application security.
No, and be wary of anyone who says yes. A review lowers risk and shows what remains, and the retest confirms the fixes. It is not a proof.
We collect real cases from your work, agree what a good answer looks like, and score the system against them, including cases where the right behaviour is to refuse or hand off. The set is rerun on every change.
Wherever an action is hard to undo: spending, sending, deleting, changing a record of truth. We set the approval rule by risk and log each approval.
Yes, and it goes better that way. We share scope, method and findings with them, and write the report so that it can go into your risk process.
We help produce the technical evidence that compliance work asks for: logging, oversight and documentation. We are not a law firm and we do not give legal advice. For the EU AI Act, see the readiness page.
We start with the problem, then tell you whether it is worth building.
Bring us a bottleneck