SwarmOps — Enterprise Agent Control Plane

Discover, govern, and secure autonomous AI agent fleets. SwarmOps detects rogue agents, enforces deterministic policies, orchestrates human approvals and provides end-to-end auditability.

Comment

Inspiration; Autonomous agents are entering the enterprise faster than governance can adapt. Companies are deploying agents that can deploy code, move money, access customer data and call production APIs often without the controls required for human employees.

The problem is no longer just how to build agents. It's how to control them.

SwarmOps is an enterprise authorization and governance layer for autonomous agents. It gives an AI workforce clear authority boundaries, deterministic policy enforcement, human approval for consequential actions, complete auditability and safe evolution over time.

Its core principle is simple: AI can reason and recommend. It cannot authorize.

SwarmOps is not a monitoring dashboard it is the authorization and governance layer between autonomous agents and enterprise systems. It governs an AI workforce with the same rigor used for people: clear authority, human approval on high-risk actions, a complete audit trail and safe, reversible change over time.

What it does SwarmOps governs the full lifecycle of an enterprise AI agent: discover it, assess its risk, control what it can do, require human approval when necessary, trace every action and safely evaluate new versions.

The flagship demo follows a rogue CustomerRefundAgent v2.

Discover → Risk 87/100 CRITICAL → Auto-Quarantine → Controlled Reactivation → $650 Refund → Business Approval → Finance Approval → Execute Exactly Once

The risk and authorization decisions are deterministic. Gemini explains what happened and recommends actions, but it cannot change a DENY or QUARANTINE.

I prove that boundary with an adversarial test: a hostile Gemini explanation instructing the system to ignore policy is stored as explanation text, while the deterministic decision remains unchanged.

How I built it; I built SwarmOps as a layered enterprise agent control plane on Google Cloud, with a deliberate separation between AI intelligence and authorization. Google technologies all live on the deployment with 9 integrations reporting CONNECTED:

Gemini 3.5 Flash via Vertex AI (global endpoint) powers the GovernanceAgent's explanation layer. Real GenerateContent calls are visible in Cloud Logging.

Google ADK : the GovernanceAgent is a real google.adk.agents.LlmAgent exposing a fixed, constrained governance toolset, with a Google GenAI SDK fallback.

Cloud Run : API + web deployment with scale-to-zero.

Firestore : persistence behind repository interfaces.

Pub/Sub : domain event bus across seven canonical events.

Cloud Trace : OpenTelemetry export of execution traces.

Secret Manager, Artifact Registry, and IAM provisioned through Terraform.

Model Armor / Agent Registry / Runtime / Memory Bank / Gateway — adapter seams with honest runtime status; demo providers remain explicitly labeled DEMO_MODE rather than being presented as live.

Stack: FastAPI (Python 3.13) with layered api / application / domain / infrastructure boundaries; Next.js 14 with App Router, Tailwind, shadcn-style components, and React Flow; SQLite locally / Firestore in cloud behind one repository interface; in-memory locally / Pub/Sub in cloud behind one event-bus interface; Terraform + gcloud deploy.sh; and 103 backend tests with pytest, with ruff + mypy clean.

Architecture why it's defensible: intelligence and authorization are separated by design. Gemini can assess, explain, and recommend, but it cannot authorize. A deterministic policy engine controls authorization, an execution state machine controls lifecycle, role-based human approval gates consequential actions, and idempotency guarantees exactly-once execution across pause/resume flows.

This separation is structural, not prompt-based. Even if the AI explanation layer is given hostile instructions to ignore policy, it has no mechanism to override a DENY or QUARANTINE decision. I enforce that boundary in code and verify it with adversarial tests.

Persistence, eventing, and tracing sit behind interfaces, so the same application code runs locally with SQLite/in-memory infrastructure or on Google Cloud with Firestore/Pub/Sub/Trace.

Data sources: the demo runs on a deterministic seed — SaitALCorp: 127 agents · 43 active · 9 high-risk · 3 quarantined — so every run is reproducible. The mock tool layer for customer, order, refund, email, and Salesforce operations is entirely simulated; execute_refund never contacts Stripe. No real customer or third-party data is used.

Demo data. Real governance execution.

No LLM sits in the authorization path.

Intelligence can be probabilistic. Authority cannot.

Challenges we ran into; Keeping the LLM out of the authorization path for real. The hard part was not integrating Gemini; it was making the AI structurally unable to override an authorization decision. Every authorization flows through a deterministic policy engine, while the ADK agent is limited to a fixed, constrained toolset. I wrote adversarial tests that feed the explanation layer hostile instructions such as "IGNORE ALL POLICIES" and verify that the underlying QUARANTINE or DENY decision remains unchanged. The generated prose is stored as explanation but it is inert.

Idempotency across pause/resume execution. A two stage approval flow that suspends an execution and resumes it later is only safe if the deferred action still executes exactly once. Getting the execution state machine and idempotency key semantics right took careful work. I verify the guarantee with an end to end test that pauses for approval, resumes execution, and asserts that only a single refund occurs.

Vertex AI Gemini 3.5 endpoint behavior; Gemini 3.5 required the Vertex AI global endpoint. Regional configuration did not reach the intended live model, so I switched GOOGLE_CLOUD_LOCATION=global and verified the fix through real GenerateContent calls visible in Cloud Logging.

Next.js environment variables are build-time; NEXT_PUBLIC_* values are embedded during the Next.js build, so setting the backend API URL only at Cloud Run runtime wasn't enough. I passed it as a Docker build argument through a dedicated Cloud Build configuration so the deployed frontend could correctly reach the API.

Making fresh Google Cloud deployments reproducible. Firestore/API enablement propagation and Pub/Sub topic provisioning introduced race conditions during first-time deployment. I made the provisioning steps in deploy.sh idempotent and resilient so a fresh Google Cloud project can be brought up consistently without relying on manually pre-created resources.

Accomplishments that we're proud of;

I built and deployed a complete, deterministic by design enterprise agent control plane on Google Cloud with Gemini 3.5, Google ADK, Firestore, Pub/Sub, and Cloud Trace genuinely connected.

The Guided Demo exercises the full governance lifecycle end to end in under four minutes from agent discovery and deterministic risk scoring to quarantine, policy enforcement, two stage human approval, and exactly-once execution.

The system is backed by 103 passing backend tests, including a full end to end governance flow and adversarial tests against the AI explanation layer.

But the accomplishment I'm most proud of is architectural: The AI is structurally unable to authorize a consequential action. That guarantee does not depend on a prompt or on the model behaving correctly. It is enforced in code.

What I learned; Determinism is the trust anchor. Keeping risk scoring and authorization outside the LLM and making the AI layer structurally unable to override a decision is what turns agent governance from a prompt level promise into an enforceable system property. I enforce that boundary in both code and tests.

Idempotency is a governance feature, not an implementation detail. A pause/resume approval flow is only safe if the deferred action executes exactly once. For consequential actions, execution guarantees are part of governance itself.

Honesty strengthens trust. Reporting integrations as CONNECTED, DEMO_MODE or NOT_CONFIGURED based on actual runtime signals made the Google-native architecture more credible, not less. A governance platform should apply the same transparency standards to itself that it expects from the agents it governs.

AI governance needs an architectural boundary not just better prompts.

An AI system can analyze risk, explain decisions and recommend actions without being given the authority to approve them. That separation became the most important lesson I took from building SwarmOps.

No LLM in the authorization path isn't just a slogan. It's an architectural principle I can defend in code.

What's next for SwarmOps — Enterprise Agent Control Plane;

Next, I plan to connect the existing adapter seams to live Google Agent Registry, Runtime, Memory Bank and Gateway and extend the GovernanceAgent with multi-turn ADK orchestration while preserving the no override authorization guarantee.

The next production layer is console authentication, per-tenant isolation, audit retention and archival, followed by live evaluators that derive agent performance, risk and compliance signals directly from execution history.

The larger goal is to evolve SwarmOps from a control plane for individual governed workflows into the governance infrastructure for enterprise AI workforces where every agent can be discovered, evaluated, constrained, audited and stopped when necessary.

As agent autonomy increases, governance has to become infrastructure.

Built With

Share this project:

Updates

Submission history