When we think about adopting AI in new workflows and applications at our companies, and we consider the potential dangers to our businesses of rolling it out, the main threads of the public conversation about AI dangers are not the ones we should care about most.

Existential threats (Is AI dangerous to society, humans, and life on Earth?) - While this may be a valid concern in general for society, Astra and Fable are not going to go Skynet on us. Today's models (Q4 2026) are dangerous not for the power they wield but due to the mistakes they make.

Escapes and hacking (Will AI agents escape their sandboxes and hack all our systems?) - Better, but again, not the main way we should be thinking about this, because this is less relevant in an enterprise threat model than the much more likely ways these technologies endanger the trust our customers place in us.

The immediate concerns are keeping our hugely important promises to our customers

  • Data integrity
  • Data privacy and data loss protection
  • Business continuity and data availability

So, what should we be doing beyond strenuously eval’ing for alignment and wrapping our agents in endlessly nested Matryoshka dolls of containers and sandboxes?

Give Agents User-Style Permissions

Treat each new agent like a new employee who has not yet earned trust. Establish least privilege permission boundaries. Get your agents and coding harnesses to help overcome the traditional difficulties of achieving this principle better than ever before! Don’t reuse permissions across agents that have different jobs. Some agents should have service accounts or non-user principal credentials, but many of them should be treated much like a human user, both in terms of how permissions are assigned, and how they would be revoked in case of any incident.

Wall Off Credentials

Assume that agents can be prompt injected or otherwise fooled into disclosing credentials such as application API keys, OAuth client secrets, and so on. Some agentic frameworks allow credentials to be stored encrypted and injected into requests in a way that the agent cannot access the credentials directly to bring them into context (sharing them with a model provider, for example) or leak them either accidentally or through misuse by an attacker. If you’re wondering whether this restricts which agent frameworks we can safely use, the answer is yes.

Aim for Maximum Determinism in Business Actions

The three popular mechanisms in widespread use to give agents access to applications can introduce unpredictable behavior when models decide each action on the fly:

  • MCP → API: MCP can give a model access to an API. When the model chooses which operation to call and what arguments to pass, those choices are non-deterministic, vibed on the fly by the model, and subject to hallucination and confusion of intent, resulting in unpredictable behavior (not to mention excess token burn for operations that don’t require intelligence).
  • Tool calls (e.g. command line execution): Same as with MCP, this can allow a model to decide on the fly to execute a workflow. It’s rolling the dice and asking for high reliability and repeatability in a world of RNG.
  • Computer use: This is even less deterministic than MCP and tool calls, because it introduces additional variables of visual interpretation of screens and user interfaces, as well as the insulation of a model operating a user interface using keyboard and mouse operations intended as an analog-to-digital interface for humans. And again with the token burn!

In the Monarch platform, our version of application use converts as much as possible within a workflow to deterministic steps, executed via our Product Graph. Agentic steps within the workflow can still provide the ability to make judgment calls, transform natural language, and take steps once only possible by people, but they do so without giving models dynamic access to applications during workflow execution.

Proxy and Log All Activity, Flag and Review

Web proxies have been providing logging and safety in browser user environments in enterprises for decades (for example, to protect users’ machines from drive-by downloads, malicious ads, and browser-delivered malware in general). Our agents need similar techniques to protect them as well as to monitor what they do in real time, and capture logs to investigate misbehavior after the fact. In addition, a classifier that has man-in-the-middle access (or, today, agent-in-the-middle) on network activity can interrupt malicious or accidental behavior before it impacts the business. And of course, the model provider for classification steps needs to meet the compliance targets required to maintain the privacy of the data that reaches it. In Monarch, the telemetry is already in place.

Test and Validate, then Promote to Prod

We can’t simply fire-and-forget agentic actions on data that matters. Before running any agentic workflow (or non-agentic) in production that changes data at its system of record, testing is an absolute necessity, both to verify the workflow behaves as expected and to ensure non-functional predictability such as acceptable performance impact, capacity consumption, auditability, error handling, and so on. With AI workflow tooling especially, we need to verify behavior in a non-production environment, then promote a tested workflow unchanged to production, and when feasible perform a dry run that reports what it would change, before allowing a real production transaction.