Why I am building Aethis

I started Aethis because I wanted a reliable way to stop AI agents from overspending.

A budget alert can tell you that something went wrong. But if the money has already been spent, the alert has not enforced a limit. I wanted the check to happen while there was still an opportunity to stop the request.

That led me to a broader question: what is an agent actually allowed to do?

Spending money is one example. An agent might also change someone’s account access, update a database, deploy a service, or send an email on your behalf. These are useful capabilities. They also mean that a mistaken decision can become a real consequence before anyone notices.

I want to use agents for meaningful work. To feel comfortable giving them that work, I need a clearer way to define their boundaries.

That is why I am building Aethis. For me, AI agent governance means defining what an agent may do, enforcing those boundaries, and keeping a record of what happened.

Give agents room to work

Imagine an operations agent helping a team keep a service running. The team might want it to:

• Read logs and inspect service health without asking.
• Restart a service in staging when an agreed condition is met.
• Request approval before deploying a specific release to production.
• Never delete a protected production database through its assigned tools.

Those are four different decisions. Asking for permission every time would interrupt useful work. Giving the agent unrestricted access would ignore the differences between those actions.

The boundary should reflect the job the team has given the agent, the systems it can reach, and the consequences of each action.

A support team might draw that boundary around account changes and refunds. A research team might care most about spending limits and access to particular datasets. The rules differ, but each team needs a way to enforce them.

Human approval for specific agent actions

Approval is one part of that boundary.

Suppose a reviewer approves a deployment to staging. Before execution, the target changes to production. The tool might still be called “deploy,” but the action is different. The earlier approval should not authorize it.

The same applies if the release changes, the destination account changes, or the approval is withdrawn.

“Allow this tool” is too broad for those situations. The useful decision is whether this agent may take this particular action, against this target, with these arguments.

That is the distinction I want Aethis to preserve.

Why prompts and logs do not settle it

Telling an agent to be careful is useful guidance. It still leaves the agent responsible for interpreting and following that instruction.

Asking a person before every tool call creates a different problem. Routine requests compete for attention with the decisions that deserve careful review. I want people involved where their judgment matters, with enough context to make that judgment.

Logs are essential too. They help explain what happened. But recording an unauthorized action does not prevent it.

Existing permissions, isolated environments, and restricted credentials remain important. I am interested in how to connect those boundaries to the specific actions agents attempt, especially when a workflow crosses several tools and services.

What I am designing

Aethis is an AI agent governance platform designed to check supported model and tool calls before execution. That includes tools exposed through the Model Context Protocol (MCP), a way for agents to connect to external systems.

For calls routed through Aethis, the intended flow has four parts:

1. Check the policy. Evaluate the agent, destination, operation, and relevant arguments against the team’s rules. Decide whether the action can proceed, needs review, or must stop.
2. Request approval when needed. Show the reviewer the specific action and why it needs attention. Routine work within policy should proceed without an unnecessary interruption.
3. Check the approval before execution. Confirm that it applies to the action being attempted, is still valid, and has not already been used. An approval should not become reusable permission to do something different later.
4. Connect the decision to the outcome. Keep an Action Record showing what was requested, what policy decided, any human approval, and what is known about execution.

That last distinction matters. “Approved” does not mean “executed successfully.” If the outcome is unknown, the record should say so.

There is also a practical limit: these controls can only apply to supported calls routed through Aethis. If an agent retains a separate, unrestricted path to the same system, that path remains outside the boundary. The architecture notes explain the intended scope.

A mistake in my own design

The approval check deserves particular attention because I found a mistake around it in my first design.

It is easy to draw a flow that says “request, approve, execute.” The harder work is defining what that approval authorizes and what must still be true when execution happens.

I will walk through the original mistake and the revised design in a separate post. I want to share the reasoning, including where it failed, because those details are what make an architecture worth examining.

Where Aethis is today

I am a student building Aethis from Singapore. It is still mostly at the design stage: a specification and threat model, with implementation work ahead.

My next step is to test those assumptions against real workflows. I want to understand which actions teams worry about, where existing controls work well, and what people have already built themselves.

I intend to make the core that checks and records actions open source. I will also share the architecture, mistakes, and changes as the work progresses.

If you are building agents with access to real systems, I would like to hear about one action you would not let them take unattended, and how you enforce that boundary today.

Email me at dominic.tan@aethis.io. Those conversations will help shape what I build first.