v4.0.13: Decide Exactly What Your AI Employees May Run, Approve the Rest From the Chat, and Fence Them Off the Network

Last week roughly half a billion dollars went into agent security, and almost all of it was spent on the same question: where do you put the credentials when the thing holding them acts on its own? v4.0.13 answers a narrower version of that question, for anyone running their own models.

Decide exactly what your employees may run

Settings > LLM providers now has a shield button on every custom LLM. It opens that model's permissions, and there are four ways to use it: no restriction, one of three presets, or rules you write yourself.

A rule names a tool (bash, read, write, edit, grep, find, ls, or any tool), takes an optional pattern (the command for bash, such as npm *, or the path for file tools), and ends in Allow or Deny. A default action covers everything your rules do not. Deny always wins.

The presets are worth knowing before you write anything:

• Standard blocks the commands that actually hurt: sudo, ssh, scp, rsync, docker, git push, npm publish, crontab, shutdown, reboot. It deliberately lets npm install, pip install, curl and git through, because an employee that cannot install a package cannot do its job.
• Strict allows reading, writing files, the employee's own skills and a handful of safe commands like cd, ls and cat. Everything else, npm and pip and curl included, is blocked.

Each preset tells you plainly what it blocks and what still runs, and every rule set ends with an explicit line: "Everything else: Allow" or "Everything else: Deny". No guessing at the edges.

Two details that matter more than they sound. A blocked action never runs, no matter how insistently the model argues for it, and the employee is simply told it is not allowed. And wrapped commands are caught, not just bare ones: cd x && npm i, bash -c "npm i", timeout 30 npm ci, env X=1 npm start all get checked properly.

Ask, for the things you cannot decide in advance

A rule, or the default action, can be set to Ask instead of deciding.

When it fires, the employee's chat shows a card with the command or tool and two buttons, Allow and Refuse. Anyone who can open that chat may answer. Once answered, the card disappears from every open chat at once, and the employee carries on. If nobody answers within 15 minutes, it is refused.

The precedence is fixed and simple: Deny beats Ask, Ask beats Allow.

This is the setting most teams will actually live in. A blanket Deny on anything touching production is easy to write and annoying to work around. Ask lets you keep the gate without pretending you can enumerate every case in advance.

A journal, and a way to test before you commit

The same window keeps a journal of the most recent actions blocked, approved, refused or left unanswered, with the employee, the date and who decided. That last column is the one that matters in a month, when somebody asks who approved a thing.

And there is a tester. Type a command, npm install express for example, and it tells you immediately whether it would be allowed, asked or blocked, and which rule decided it. It works against the rules currently in the window, saved or not, so you can check your logic before committing to it.

Network access, per model

Next to the shield is a globe. It controls what the model's employees can reach on the network, saved separately from the command rules.

Three modes: no restriction, block these IP addresses, or allow only these. Each mode keeps its own list, so switching between them does not destroy what you wrote. Lists take IPv4 addresses and ranges, one per line, such as 10.0.0.0/8. An empty "only these" list means no internet at all. Anything that is not a valid IPv4 address or range is refused rather than silently ignored.

DNS and Geta.Team itself always stay reachable, otherwise nothing would work.

The rules also cover the pages Geta.Team opens on the employee's behalf through its server-side browser. A refused address will not load, and neither will any image or script a page pulls from one. The attempt lands in the journal.

Both sets of rules follow the model. Switch an employee to a different custom LLM mid-conversation and that LLM's command rules apply from the next command, with its network rules applying immediately.

The queue that could stay stuck for an hour

This is the fix worth reading even if you never touch permissions.

While an employee is working, messages arriving from WhatsApp, Gmail and other channels wait in a queue and go out when it finishes. The problem was the "done" signal from the streaming engines: it only reached the platform when the connection happened to be attached to the employee's session. When it was not, the signal was lost. The employee looked busy forever, and the queue stayed blocked, sometimes for an hour or more, until somebody reopened the chat and unjammed it by accident.

Three changes. The "done" signal now reaches the platform in every case. There is a safety net, so an employee that looks busy while its engine has said nothing for 15 minutes is treated as done and the queue moves on, logged as a warning. And queueing and hand-over are now written to the server logs, so the next oddity here is diagnosable rather than invisible.

If your employee has ever gone quiet on WhatsApp for no reason you could identify, this was probably it.

Also fixed

Long messages now appear in the chat. Anything over 100 KB sent to the chat, an image for instance, was refused by the engine, and the error was silent. Those messages simply never showed up live. The limit is now 15 MB, and a refused message gets written to the log instead of vanishing.

WhatsApp contact cards and locations reach the employee. A vCard sent on WhatsApp was dropped as an empty message, so nothing arrived while the text around it did. The employee now receives it as text with the contact's name, phone numbers, emails and company. Several cards at once arrive as a numbered list. Shared and live locations arrive too, with name, address and a map link.

Meetings start their sound and transcript immediately. When the Join screen was skipped, the room still waited for a click before enabling sound and the transcript, and showed a "turn on sound" banner anyway. It now uses the same check the skip does.

Desktop app 1.0.60, Mac and Windows

Some people found the app had closed itself in the background, after an Alt+Tab or while sitting in the tray, and stayed frozen when reopened. Nothing was written to the log, so the cause could not be found.

Now every crash is logged with its reason: a page whose process is gone, a page that stops responding and when it responds again, or a helper process dying. A crashed page reloads itself, capped at three times a minute so a page that crashes on load cannot loop. Coming back from the tray redraws every page and reloads any that crashed while hidden. And launching the app again while it is already running is logged with the window state, opening a new window if the old one is gone rather than appearing to do nothing.

Why this release matters

Most agent security being sold right now is about watching agents from the outside. This is the other half: deciding in advance what the thing is allowed to do, in the place where it runs, with an answer that does not depend on the model agreeing.

That distinction matters most if you run your own models, because you are the one who chose them and you are the one accountable for what they touch. Presets get you to a sane default in a minute. Ask keeps a human in the loop without blocking real work. The journal means you can answer the question afterwards.

Want to test the most advanced AI employees? Try it here: https://Geta.Team