Bound values the model never sees
Fix any parameter the model has no reason to choose: an account, a unit, a flag. Maitento adds it to every call, and the model can’t see it, change it, or be talked into another.
Read how it worksSecurity
Agents that act, with guard rails built in
Agents call real APIs, run real code and handle real secrets. Maitento decides what they can see, where their code runs, and what waits for a person, and keeps a record of all of it.
The principle
The model sees a tool. Maitento holds the rest.
Three tools from the support desk in tutorial 23. The agent chooses an order id and a search; Maitento adds the key, binds the knowledge base from the run, and holds the refund until a person approves it.
What the agent sees
find-order(orderId)Looks up an ordersearch-policies(query)Searches the shop’s policiesissue-refund(orderId, amount)Refunds an orderneeds approval
No URLs, no keys, no account ids, no other parameters.
What Maitento sends
GET https://shop.example/orders/A-1001X-Api-Key: •••••••• from the secret shop-api-keyAdded by MaitentoPOST knowledge-search{ "partitionId": this run’s knowledge base, "query": "faulty item refund" }Bound from the runPOST https://shop.example/orders/A-1001/refundheld until a person approves itApproval
Agents only see the surface you give them
A tool is what an agent sees of an API, and you decide all of it. Everything else is filled in by Maitento, outside the model’s reach.
Values from the run, not the model
Per-customer values, such as the knowledge base or shop to use, come in with each run and go straight into the call. The model never chooses whose data it touches.
Read how it worksCredentials stay out of the conversation
Maitento adds the secret to the request itself. The model sees a tool’s name and guidance, never a key, a token or a password.
Read how it worksCode runs in isolated containers, not in your infrastructure
Agents that run code do it on Maitento, in throwaway Linux containers: not on your laptop, not on your servers, and not inside your network.
Throwaway sandboxes with time limits
Capsules and code pipelines get a fresh container that ends when its commands finish, when you stop it, or when its time runs out. Nothing to host, patch or clean up.
Read how it worksNo way into private networks
Connectors, webhooks and model endpoints only reach the public internet. Loopback, private, internal and cloud-metadata addresses are refused, and checked again each time a name is resolved, so there is no escape route to manage.
Read how it worksLimits on every run
Time limits on interactions, apps, capsules and code pipelines; caps on sub-runs and dispatches; and prepaid usage, so a runaway agent stops instead of running up a bill.
Read how it worksPeople in the loop, and a record of everything
Agents act; people decide what matters. Every run leaves a record you can read back.
Approval before risky actions
Mark a tool as needing approval and the run stops before calling it, until someone approves, or rejects it with feedback the agent can act on. Waiting is never charged.
Read how it worksEvery run on the record
Each run keeps its conversation, every tool call and its arguments, approvals, timing and tokens, and which of your credentials served it, for as long as your plan’s retention allows.
Read how it worksLive events and signed webhooks
Watch runs as they happen over events, or have Maitento call you when they finish, with a signature so you know the call is genuine.
Read how it worksYour keys and your data, protected
Maitento has no models of its own, holds your secrets so nobody can read them back, and keeps each tenant’s data under its own key.
Your model keys, your provider account
Every model call goes to your provider on your own account, under your agreement with them. Give each of your customers their own keys with credential stacks.
Read how it worksWrite-only secrets
Store API tokens and passwords as secrets. Definitions refer to them by name, and no route, SDK call or command reads a value back.
Read how it worksEncrypted at rest, under your own key
Secrets and credentials are encrypted at rest with AES-256-GCM under a key that belongs to your tenant alone, itself protected by a root key that never sits in the database. One tenant’s key never unlocks another’s.
Deleted means deleted
Your tenant’s data is bound to your tenant’s key. Destroy the key and every copy, backups included, becomes unreadable.
Encrypted in transit, kept out of logs
Everything travels over TLS, and secrets are redacted before anything is logged.
Sign in your way
Sign in with GitHub, Google or Microsoft on every plan, and give each of your applications its own API key.
Found a security problem?
Please tell us privately before telling anyone else: report it through GitHub’s private vulnerability reporting ongithub.com/maitento/maitento, or contact us.