Build / AI Agent Development
Agents with scoped tools, least-privilege access, an audit trail and explicit approval boundaries for anything consequential.
TechSteps builds AI agents that connect to real systems, with scoped tools, least-privilege access, an audit trail and explicit approval boundaries for consequential actions. The engineering effort goes into what the agent is permitted to do and how that is enforced, because an agent that can act on production systems is a security design problem before it is an AI problem.
What this solves
An agent differs from an automation in one important way: it decides which actions to take. That is what makes it useful and what makes it dangerous.
Most agent demonstrations skip the part that matters. They show a model calling tools successfully. They do not show what happens when the model calls the wrong tool, calls the right tool with wrong arguments, or is manipulated by content it processed into taking an action nobody intended.
We build agents the way we would build any system with production access: least privilege, explicit boundaries, everything logged, and a human in the loop for anything that is expensive to undo.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
What may it read, what may it change, and what always needs a person. This is the design, and everything else follows from it.
An agent that gathers context, drafts and recommends is useful immediately and carries very little risk. State-changing capability is added deliberately, one tool at a time.
A tool that updates one field with validated arguments is far safer than a general-purpose tool that runs arbitrary queries. Narrow tools are also easier for the model to use correctly.
Anything the agent reads, an email, a web page, a document, may contain instructions aimed at it. The system must not treat content as a source of commands.
Run with full logging and review the transcripts before widening access. Real transcripts show the failure modes a specification never anticipates.
Permissions expand because the logs justify it, not because the demo was impressive.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
A tool that executes arbitrary queries or commands gives the agent the full permission of the account behind it. The blast radius of a single mistaken call becomes unbounded.
The agent reads a document containing text aimed at it and acts on it. If the agent has write access, this turns any content it processes into a potential command channel.
A confirmation step that always says the same thing gets approved reflexively. The prompt has to show what will actually change.
Something changed, nobody can say why, and the only record is a model response nobody kept. Accountability disappears.
The agent acts as a person, so its actions are indistinguishable from theirs in the logs, and it inherits every permission that person has.
Questions we actually get asked
Mostly by not giving it the capability. Destructive actions either are not exposed as tools at all, or are exposed behind a human approval gate that shows exactly what will change. The model's judgement is a useful layer and it is not the control. The permission boundary is.
It is when content the agent processes contains instructions aimed at the agent, and the agent follows them. It matters as soon as your agent both reads external content and can take actions. The mitigation is architectural: keep instructions and data separate, treat all processed content as untrusted, and gate consequential actions behind approval so a successful injection still cannot do much.
Yes, through retrieval over your own systems with permissions respected. An agent should not be able to surface a document to someone who could not otherwise access it, which means the permission model has to be enforced at the retrieval layer rather than in the prompt.
An automation runs a fixed sequence you designed. An agent decides which steps to take. Agents suit processes needing judgement about what to do next. If the steps are always the same, an automation is cheaper and more predictable, and we will tell you when that is the better answer.
You are, which is why the design matters. Our job is to ensure mistakes are bounded, visible and reversible: narrow tools, approval on consequential actions, full audit logs, and rollback where the action allows it. We agree the accountability model before deployment, not after an incident.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.