Why We Started AgenticWork: Security-First AI Agents for the Enterprise

We started AgenticWork in March 2025 because we could not find an AI agent platform that took security seriously from the architecture level.

Every framework we evaluated — LangChain, CrewAI, AutoGen, OpenClaw — followed the same pattern: give the agent access to everything, hope nothing goes wrong, and add guardrails later when something inevitably does. Tools had blanket API keys. Agents could call any endpoint with any credential. Audit trails were optional. Sandboxing was an afterthought. The “security” section of most frameworks was a paragraph suggesting you add rate limiting.

This is backwards. In enterprise environments — finance, healthcare, government, defense — you cannot start with “agents can do anything” and work backward to “agents can only do what they should.” You have to start with zero trust and selectively grant capabilities. Every action must be auditable. Every credential must be scoped. Every tool invocation must be governed.

The Problem We Saw

In early 2025, the agentic AI space was moving fast but building on shaky foundations. Teams were connecting agents to production databases with admin credentials. MCP servers were being deployed with no authentication, no input validation, and no audit logging. Supply chain attacks were starting to hit AI tool registries. And most frameworks treated model selection as a hard-coded config option — pick one provider, hope their API stays up and their pricing stays sane.

We watched enterprise teams try to adopt these tools and hit the same walls:

• Security teams blocked deployment because there was no way to scope agent permissions, isolate credentials, or produce compliance-grade audit trails.
• Engineering teams got locked into single providers because switching from OpenAI to Anthropic or running local models meant rewriting agent logic.
• Operations teams could not monitor what agents were doing because most frameworks logged completion tokens, not decisions and actions.
• Compliance teams had no path to EU AI Act or NIST AI RMF conformance because the audit infrastructure did not exist.

What We Decided to Build

AgenticWork started with four architectural principles that every component would be built around:

1. Multi-Model, Multi-Provider by Default

No enterprise should be locked into a single LLM provider. Our model routing layer — what we now call SmartModelRouter — was one of the first things we built. The idea was simple: analyze what each task actually requires, route to the right model tier, and make provider switching a configuration change — not a code rewrite. Economy tasks go to fast, cheap models. Complex reasoning goes to frontier models. And if one provider goes down, the request fails over to the next one automatically.

From day one, we supported Anthropic, OpenAI, Google Gemini, AWS Bedrock, and self-hosted models through Ollama. The agent code never knows or cares which provider is handling the request.

2. Credential Isolation, Not Credential Sharing

Every other framework we looked at gave agents a bag of API keys and let them use whatever they wanted. We built credential isolation into the execution model: each tool invocation gets a scoped, time-limited, task-specific credential. A tool that reads from S3 gets a pre-signed URL that expires in 30 minutes. A tool that writes to a database gets a connection with INSERT-only permissions on the specific table it needs. When the task is done, credentials are revoked and the execution environment is scrubbed.

This is not a nice-to-have security feature. This is the baseline for any system that interacts with production infrastructure on behalf of users.

3. Immutable Audit Trails

If you cannot prove what an AI agent did, when it did it, and who approved it, you cannot deploy it in a regulated environment. Period. Our audit system records every agent decision, every tool invocation, every approval gate, and every model routing decision in cryptographically hashed, immutable logs. Not optional logging. Not “turn on debug mode.” Every action, every time, tamper-evident by design.

4. Human-in-the-Loop as Architecture, Not UI

Most frameworks implement human-in-the-loop as a confirmation dialog: “Are you sure? [Yes/No].” That is not governance. Real HITL means policy-based approval gates that agents cannot bypass — enforced at the architectural level, not the UI level. Low-risk read-only operations can be auto-approved with full logging. High-risk operations require explicit human review. Critical operations require escalation. The agent cannot circumvent these gates because they are part of the execution pipeline, not a wrapper around it.

On-Demand Tool Synthesis

One of our early insights was that the traditional model of pre-building tool integrations was fundamentally broken for enterprise environments. Every tool is a maintenance burden. Every MCP server is an attack surface. And most tools sit unused — enterprise tool registries tend to accumulate hundreds of registered tools while agents in practice rely on only a small fraction of them.

So we built OATS — On-demand Agent Tool Synthesis. Instead of maintaining a library of pre-built tools, agents describe what they need in natural language. The platform synthesizes a purpose-built tool, shows the generated code to a human for approval, executes it in a sandbox, and discards it. No persistent tool library to maintain. No MCP servers to secure. No integration debt accumulating over time.

OATS is one capability of the platform — it handles the tool execution layer. SmartModelRouter handles model selection. The Workflow Builder handles orchestration. The Audit System handles compliance. Credential isolation handles security. Together they form a complete, governed AI agent operating environment.

Deploy Anywhere

From the start, we designed the platform to run on the customer's infrastructure — not ours. Kubernetes-native deployment. Air-gapped environments supported. Private cloud, on-premise, hybrid. Your data never leaves your perimeter. Your models can run locally through Ollama or connect to cloud providers through your existing VPN.

This was a deliberate choice. Enterprise AI infrastructure should not require sending sensitive data to a third-party SaaS platform. The deployment model should match the security model.

What Comes Next

We are committed to transparency, with an open-source release planned. The OATS framework is part of the platform. The platform is approaching early access for enterprise teams. We will be publishing detailed technical deep-dives on each component as we ship them.

If you are building agentic AI for the enterprise and are tired of frameworks that treat security as an afterthought, we are building the alternative.