AI_agents · development, security, identity
We build AI agents, and we secure the ones you already run. An agent with access to your production database is a user account nobody hired. We decide what it is allowed to touch before we build it, then go and find out what it can be talked into.
Custom scope · Written quote first · NDA before anything technical
Why_this_exists >>
01_The_shift
of respondents reported a security incident involving an AI agent in the past year. An agent does not ask permission the way a person does: it reads a ticket, decides what to do, and calls whatever it has access to. That is the entire point of it. It is also the problem. Cloud Security Alliance 2026 — 445 IT and security practitioners
02_The_gap
of organizations have had an agent exceed the permissions it was meant to have. Most ship with a shared API key and broad database access, because that was the fastest way to make the prototype work. One prompt injection later, that access belongs to somebody else — with no per-agent identity to revoke and no log of what it did. Cloud Security Alliance 2026 — 445 IT and security practitioners
Every agent, a job description.
We build agents with their limits agreed up front, and we review existing agents against what they can actually reach today. Where an agent needs a verifiable identity of its own, Atsign's identity platform is one of the tools we use.
What_we_do
build · scope · handover
We agree what the agent's job is, and what it is allowed to touch, before any of it is written. Human approval steps go wherever being wrong is expensive. You get code your own team can read.
review · test · report
For agents already running, we map what they can reach and then try to make them misbehave. Prompt injection, tool abuse, and the confused-deputy problems that appear once agents call other agents.
identity · access · audit
Most agents run on one shared key nobody can revoke without breaking everything. We give each agent credentials of its own, scoped to what it needs. Atsign's identity platform is one of the tools we use here.
How_it_works
How_we_build
An agent that is right most of the time is not a feature, it is a liability with good PR. These are the four things we do to keep that from being the thing you find out in production.
cross-checked · competing models
Most of what we build runs on Anthropic models. But a single model has a single set of blind spots, and on a decision that matters we would rather not inherit them — so we put competing models on the same question and compare what comes back.
Where they agree, confidence is cheap. Where they disagree, we have found the part of the problem that needed a person looking at it. That is useful information, not an inconvenience.
scored · criteria agreed up front
"It looks right" does not survive contact with production. Each decision an agent makes is scored against criteria we define with you before the build, so what comes out is a number you can inspect and argue with.
It also makes drift visible. A system you cannot score is a system you cannot tell is degrading until somebody complains.
RCI · recursive criticism
Generated output goes through recursive criticism and improvement: the model is made to find the faults in what it just produced, then fix them, before any of it moves on.
This is not faith in the technique — it is the opposite. It assumes the first answer is probably flawed, which is a safer place to start than assuming it is not. AI is wrong confidently, and confident mistakes are the expensive kind.
evaluated · before it ships
Every prompt that instructs an agent goes through an evaluation cycle first — run against cases where the right answer is already known, and measured rather than eyeballed.
A prompt is code. It is the part of an agent most likely to be edited casually by whoever is nearest, and the part least likely to have a test. Treating it as configuration instead of software is how agents quietly start doing something else.
None of this makes an agent correct. It makes the failures visible, cheaper, and less likely to be found by your customer first — which is the honest thing to aim for with technology that gets things wrong and cannot reliably tell you when.
Who_it's_for
new builds · greenfield
You have a job an agent could do — support triage, data entry, research, reconciliation — and nobody free to build it. We build it, with the limits designed in rather than bolted on.
agents in production
The agents work. Nobody has checked what they could do if someone got creative with the input. We find out, and we write down the answer.
compliance · audit · insurance
An auditor, a customer, or an insurer is asking how you control what your AI is allowed to do. We give you a document that answers it.
Pricing
Every agent setup is different, so this work is scoped per engagement rather than sold in tiers.
Let's scope it
A one-off review of what your existing agents can reach, and what they can be talked into.
For new builds
Let's scope it
We design, build and hand over an agent that does one specific job.
Final pricing depends on scope and is confirmed in a written quotation before any commitment.
FAQ
Both, and they are separate engagements. Some clients hire us to build one and never need a review. Others have five agents already in production and want to know what those agents can reach.
The two ask different questions. A build starts from what the job actually is, and most of the work happens before any code exists — deciding what the agent is allowed to touch. A review starts from what is already running, and most of the work is finding out what it can be talked into doing.
If you need both, they are worth keeping apart. The people who designed a system are the worst people to attack it, and we would rather hand you an honest review than a flattering one.
Usually not the model. It is the access. One shared API key across every agent, broad database permissions granted during a prototype and never narrowed, and no record of which agent did what. Prompt injection then turns all of that access into somebody else's.
The pattern repeats because prototypes ship. Permissions get opened up to make a demo work on a Friday and nobody closes them afterwards, because closing them means finding out what breaks. Six months later the agent has more reach than most of your employees and no manager.
The second failure is quieter: nothing is logged. When something does go wrong you cannot say which agent did it, on whose behalf, or what it touched. That tends to be the first question your customer asks.
A credential that belongs to one agent instead of being shared, scoped to exactly what that agent needs, and revocable on its own without breaking everything else. Where it fits, we use Atsign's identity platform to do this rather than building it from scratch.
The alternative is what most teams have: one key, copied everywhere. That works until you need to answer a question about it. Which agent made that call? Can we switch off the one misbehaving without taking down the other four? Who decided this one needed write access?
With per-agent identity those become ordinary operational questions instead of an incident. It also makes least privilege enforceable rather than aspirational — you cannot scope permissions per agent while every agent wears the same badge.
We are not tied to one, and choosing is part of the work. Most of what we build runs on Anthropic models, but the right answer depends on the job — and where a decision matters, we deliberately run competing models against each other rather than trusting any single one. Each decision is then scored against criteria we agree up front, so what comes out is a result we can check instead of an opinion we hope is right.
For deployment we work where you already are. UiPath when you want a full orchestration fleet with fine-grained control and MCP support. Atsign's AI Architect when each agent should be built from scratch with its own digital identity. Amazon Bedrock AgentCore if you are on AWS.
If the models need to run on your own infrastructure, we can do that. You get control over where your data goes. What you take on is a narrower choice of model, and the work of hosting it and keeping it updated. Retrieval over your own documents gives an agent current information to work from, but it does not make a smaller model a better one. We will tell you which trade you are making before you make it.
A 15-minute scoping call. We agree what is in scope, put that and written authorisation in place, and schedule the work.
For a review, it helps to know what the agent connects to before we begin — which systems, which credentials, which data it can read. You do not need a diagram; a list is enough. If you are not certain what it can reach, that is itself a finding.
For a build, bring the job rather than the solution. Describe the work you want done and who it is for, and we will tell you whether an agent is the right shape for it. Sometimes it is not, and that is a cheaper thing to learn at the scoping call than at the demo.
Get_started >>
Tell us what your agents do, or what you want one to do. We reply with next steps, usually a short call followed by a written quote.
Prefer email? Write to info@kryo.solutions