DEV Community: Anatolii Maltsev

DON’T trust MCP tool names

Anatolii Maltsev — Fri, 16 Oct 2026 16:20:26 +0000

Two servers expose delete_user.
Your trust list approves one.
The runtime resolves by name and may execute the other. Nothing errors and the transcript lies.

Quieter failure: MCP ships a version where transfer grows an optional destination_account field.

Yesterday it moved money, today it moves money to a chosen account.
Name unchanged, signature still valid, trust list still stale.

def tool_identity(server_id, name, schema):
    canonical = json.dumps(schema, sort_keys=True, separators=(",", ":"))
    return f"{server_id}::{name}@{sha256(canonical)[:16]}"

Unreviewed drift suspends the tool.
A flag that stops nothing is a log line.

Full writeup with the field-classification problem: here

6 enforcement paths - 6 declared defaults

Anatolii Maltsev — Thu, 15 Oct 2026 15:24:31 +0000

Fail-closed is treated as a config flag.
It is a property of six separate places, and each can become fail-open on its own:

missing rule returning allow;
recompute falling back to client-supplied values;
warm cache never re-checked against source;
blanket except;
legacy path that predates the gate, and non-atomic grant consumption.

The dependency table is where people get it wrong:

Policy evaluation fails      -> Block
Budget reservation fails     -> Block
Audit write already durable  -> Allow + retry
Telemetry fails              -> Allow + drop

Treating every dependency the same is how fail-open gets introduced by careful people.

Read full article here

Agent Budget is a Permission not a Limit

Anatolii Maltsev — Wed, 14 Oct 2026 17:40:30 +0000

A budget that reports at the end of the period is accounting.
A permission constrains the future, before the call.

The concurrency failure is the whole story.
5 workers check whether $4000 is under a $5000 cap, each sees yes, each spends $1200. Every individual check was correct.

Reserve in-flight calls instead:

def authorize(cost_cents, period):
    spent = counters.spent(period)
    held  = reservations.outstanding(period)
    if spent + held + cost_cents > CAP:
        return Decision("block")
    reservations.create(cost_cents, period, ttl=300)
    return Decision("allow")

Two settlement skews to design for up front: actual cost differing from estimate, and the settlement write failing outright.
Both are ordinary.

Full writeup with the field-classification problem: here

Human Approval Is Not Authorization

Anatolii Maltsev — Wed, 14 Oct 2026 09:33:10 +0000

A HITL step shows a tool name and a truncated preview.
The executor receives the payload. Nothing compares them.

The agent asks for a $100 refund, gets approved, decides mid-execution the situation is worse, retries at $200.
Different action, same approval.

Keying on an approval ID does not help.
The handle proves who approved, not what they saw.

Close the seam by recomputing a digest at execution time and consuming the grant atomically:

UPDATE approvals
   SET state = 'consumed', consumed_at = now()
 WHERE id = :approval_id
   AND state = 'approved'
   AND expires_at > now()
   AND digest = :live_digest
RETURNING id;

One statement, four preconditions, zero rows means refuse.
The read-then-write version passes every test and lets forty workers through.

Full writeup with the field-classification problem:
https://nullrun.io/blog/human-approval-is-not-authorization

Better, Faster, Cheaper, Same

Anatolii Maltsev — Mon, 12 Oct 2026 13:58:29 +0000

I've published a new article, "A World Full of Copies" about how AI, algorithms, and the cult of optimization are making products, ideas, and culture increasingly alike.

It explores why proven formulas often beat experimentation, why visibility gets rewarded over substance, and how the pursuit of efficiency can quietly erode originality.

The central argument: production is cheap now, but independent thinking and genuine variety are becoming more valuable than ever.

Read the full article:here

AI Agent Breach 101

Anatolii Maltsev — Wed, 07 Oct 2026 14:31:55 +0000

Your AI agent can modify a database, issue a refund, or change production infrastructure. What stops it from doing the wrong thing?

Recent AI agent incidents show the same problem: agents can reach production and execute actions their operators never intended.

Different incidents. Same missing boundary.

Five failure modes

1. Runaway execution

An agent gets stuck in a loop and keeps calling tools. A token budget isn't an execution budget. Without a hard limit, a small loop can become a large bill.

2. Destructive tool calls

An agent may have access to tools that can change production state. One wrong call can become an incident.

3. Indirect prompt injection

Agents process untrusted content: tickets, documents, emails, web pages. If that content changes the agent's behavior, execution boundaries limit the damage.

4. Incorrect tool calls

Agents can use wrong parameters, misunderstand tool results, or claim an action succeeded when it didn't. Production systems shouldn't rely on the model to decide whether a consequential action is safe.

5. Missing approval boundaries

Reading data is different from deleting it. Drafting a refund is different from issuing one. Sensitive actions need approval tied to the actual action, not just a step in the workflow.

6. Missing evidence

When something goes wrong, you need to know:

What action was requested?
With which parameters?
What policy applied?
Was it allowed, blocked, or approved?
What actually happened?

Logs are useful, but recording the execution decision is different.

The missing boundary

Agent frameworks are good at orchestrating models and tools.
But orchestration isn't authorization.

A framework can tell an agent:

Here are the tools you can use.

It doesn't necessarily answer:

Should this specific action be allowed?

If the agent can reach the tool, the action can happen.
A safer architecture puts a policy between the agent and the tool:

Agent
  |
  | action + parameters
  v
Policy
  |
  +-- allow
  +-- block
  +-- require approval
  |
  v
Tool
  |
  v
Production

The policy evaluates the actual action.

Not the prompt.
Not the agent's intentions. The action.

This is an authorization problem
Agent behavior is probabilistic. Authorization shouldn't be.

The model can decide:

I want to issue this refund.

It shouldn't decide:

I am allowed to issue this refund.

The policy can evaluate the actual request:

{
  "tool": "issue_refund",
  "amount": 4000,
  "customer_id": "12345"
}

What we're building

This is why we built NullRun.

NullRun sits between agents and the systems they can affect. It evaluates execution requests and can allow, block, or require approval before the tool runs.

It also records the decision, including blocked actions.
The goal isn't to make agents reliable.
It's to put reliable execution boundaries around unreliable decision-making.

The model can ask for anything.
It shouldn't be the authority that decides what gets executed.

Hi, I'm Anatolii. I'm building things on my own.

Anatolii Maltsev — Mon, 05 Oct 2026 14:00:00 +0000

I'm a solo founder, engineer, cyclist, photographer and unapologetic cat person. I've been in IT since 2018, but I've never been particularly good at staying inside one box.
I've worked on backend systems, automation, infrastructure, AI, microcontrollers, TinyML, blockchains, and game development. I've built things that were useful, things that were weird, and a lot of things simply because I wanted to see if I could.

Since 2022, my wife, our cat and I have been travelling around the world. With the world getting a little crazier every year, we decided to see more of it while we could. We've lived in Southeast Asia, Central Asia, and now we're in Georgia.

At some point, building things stopped being something I did on the side.
It became the job.
Over the last year I've been working on AI systems as a freelance engineer. I've built RAG systems, multi-agent workflows, support systems, document automation and integrations with external platforms.

And eventually I kept running into the same problem. AI agents are getting very good at deciding what to do. I'm much more interested in what happens when they actually do it.

An agent can send an email.
It can issue a refund.
It can modify customer data.
It can delete something.

The model might have a good reason. It might have a bad reason. It might be completely wrong. Either way, something still has to decide whether that action is allowed.
That became the idea behind NullRun, the company and product I'm building now.

NullRun sits between an AI agent and its tools. Before an action executes, it checks the declared policy against the actual action and returns allow, block, or require_approval.
I'm building the whole thing myself: architecture, Rust backend, Python SDK, infrastructure, product and the parts of the website I probably shouldn't be spending this much time on.

The product is still early. No customers yet. No team. No funding.
Just me, a codebase, and 91 names in a spreadsheet that I'm slowly trying to turn into conversations.
That's also what I want to write about here.

I'll write about building a company as a technical founder, making product decisions without a big team behind you, engineering systems that have to behave predictably, and the things I learn when ideas meet actual users.

I'll also write about the technical side of agent execution, security and runtime authorization when there's something worth digging into.

And occasionally I'll probably write about cycling, photography, travelling, or some completely unnecessary thing I decided to build.
That's what I'm doing these days.