Enterprise Agent Platform: Security-First AI Agent Infrastructure in Go

Most AI agent demos end where the enterprise begins: authentication, audit trails, cost controls, and a human who can say no before a tool call runs. Enterprise Agent Platform is an open-source Go monorepo built around that exact gap. It is a security-first infrastructure layer for autonomous AI agents — an API gateway that fronts agent work, a permission system that decides who may do what, a sandboxed execution model, a multi-provider LLM gateway with cost budgets, and a human-in-the-loop service that can halt dangerous actions on a dead man's switch.

The repository (github.com/Shivay00001/enterprise-agent-platform) ships as a single Go module with real, reviewable code — not a slide deck. The modules that matter are all present and concrete: an agent execution engine, JWT + RBAC auth, a multi-provider LLM gateway with circuit breakers, an injection/SSRF security scanner, a compliance layer with OPA policies, an immutable audit service on NATS JetStream, a human-in-the-loop review service, and deployment assets (Kubernetes manifests, a hardened Dockerfile, a Grafana dashboard, load tests, and CI workflows). One caveat is worth stating up front, because honesty is the point of this series: the README's architecture diagram names gVisor sandboxing, Temporal orchestration, and WASM tool plugins as deployment targets, but the code I verified centers on the implemented Go services. The sandboxing story is design-stage; the auth, agent loop, LLM gateway, HITL, and audit code are real.

The problem it solves

Run a capable agent for a business and three risks appear within days. First, the agent spends real money: every tool call burns tokens, and without budgets an agent can loop itself into a four-figure API bill. Second, the agent touches real systems: databases, email, browsers, payment flows — tool calls are not chat messages, they are actions with consequences. Third, the agent reads the hostile internet: prompt injection, malicious URLs, and social-engineered instructions are routine, not exotic.

Most agent frameworks treat these as documentation chapters. This platform treats them as architecture. Every request crosses an API gateway with TLS and mTLS. Every action passes through an RBAC permission matrix where, per the code comments, "any change here requires a security review and is captured in the audit log." High-risk tool calls pause for human approval with an SLA timer — and if the timer expires, the action auto-cancels rather than auto-approving. That last property is the dead man's switch, and it is the single most important line in the whole design.

How it works

The agent loop: Think → Plan → Act → Observe → Verify

The core is internal/agent/engine.go. A Task is the top-level unit of work and carries the metadata an enterprise cares about: user_id, org_id, a token_budget, and a cost_budget_usd. The task lifecycle is an explicit state machine — pending, planning, running, awaiting_human, completed, failed, cancelled, and tellingly, budget_exceeded. An agent that has burned its budget does not get a new one; it gets a terminal state.

Each iteration of the loop is a Step holding a thought, tool calls, observations, and a Verified flag. Progress is serializable as a Checkpoint — step number, message history, tokens used, dollars used, timestamp — so a task can be resumed, inspected, or audited after the fact. That checkpointing is what turns an agent from a black box into an inspectable process.

Auth: JWT, mTLS, and a granular RBAC matrix

internal/auth/ splits into token handling (auth.go: JWT issuance and validation, mTLS) and authorization (rbac.go). The RBAC layer defines a Permission type with fine-grained constants that read like a threat model made concrete: task:create, tool:invoke:high_risk, tool:invoke:critical, hitl:approve, audit:export, compliance:override, model:high_capability. Roles map to permission sets in a rolePermissions table declared as the authoritative matrix. The design instinct is right: permissions are strings with namespaces, so new tools and risk levels slot into the existing grammar instead of requiring schema changes.

The LLM gateway: providers, circuit breakers, budgets

internal/llm/gateway.go fronts four providers — Anthropic, OpenAI, Google, and a local provider — behind a single interface with a hand-rolled circuit breaker. The breaker is a textbook implementation done carefully: closed / open / half-open states managed with atomic operations, a failure threshold that trips it, a reset timeout after which a single half-open probe is admitted (halfOpenLimit: 1), and counters for failures and successes. In production agent systems, provider failover is where outages hide; the circuit breaker means a dead provider stops the loop instead of hanging it. Combined with the task-level token and cost budgets, this is the economic firewall: the agent cannot spend what it was never allocated.

Human-in-the-loop with a dead man's switch

internal/hitl/service.go is where the platform refuses to trust the agent alone. A Review record captures everything a reviewer needs: task ID, tool name, input arguments, a risk score, and an expiry time. Review statuses cover pending, approved, rejected, modified (reviewer edits the arguments rather than just voting), and expired. The service is backed by Redis with a configurable SLA. The semantics matter: expiry does not mean approval. An unanswered high-risk action dies. In safety-critical tooling this is the only sane default, and it is implemented at the service level rather than documented as a suggestion.

Security, compliance, and the immutable audit trail

internal/security/ handles injection detection, SSRF validation, risk scoring, and SQL injection scanning. The README describes the defense posture as layered: pattern matching, semantic similarity, structural separation between instructions and data, tool-call validation, and output validation. Outbound URLs are validated against private IP ranges before execution — the standard SSRF countermeasure — and the README lists explicit non-goals (no CAPTCHA bypass, no Tor evasion, no scraping sites that disallow bots), enforced in code rather than policy.

internal/compliance/ enforces robots.txt on every navigation, maintains a domain deny list, applies per-domain rate limiting, and ships an OPA policy bundle (opa-policy.rego) so compliance rules can be managed as policy, not code.

The audit service (internal/audit/service.go) is genuinely wired to NATS JetStream — the import is github.com/nats-io/nats.go and the service holds a nats.JetStreamContext. Every action produces a cryptographically chained, tamper-evident audit event, designed to land in S3 with Object Lock retention. Immutable audit is what makes the RBAC matrix and the HITL decisions provable after the fact; without it, both are theater.

Supporting infrastructure

Around the core sits the tooling a real deployment needs: Prometheus metrics and health probes (internal/observability), structured logging with correlation-ID propagation (pkg/logger), AES-256-GCM encryption and ECDSA signing (pkg/crypto), structured domain errors with HTTP statuses (pkg/errors), environment-based configuration with fail-fast validation (pkg/config), a tool registry (internal/tools), a Playwright browser pool (internal/browser), Kubernetes manifests with network policies and HPAs, a hardened multi-stage Dockerfile, a Grafana dashboard, k6 load tests (tests/load/k6-staging.js), and GitHub Actions workflows for CI and deploy. Entry points live in cmd/: the main cmd/server wiring everything together, plus cmd/gateway, cmd/audit-service, and a cmd/test_agent for exercising the loop.

How to run it

Prerequisites are Docker Compose, Go, and the usual local services. The development flow, per the README:

git clone https://github.com/Shivay00001/enterprise-agent-platform.git
cd enterprise-agent-platform

# Start dependencies (Postgres, Redis, NATS, Vault, Temporal, OPA)
docker compose -f deployments/docker/docker-compose.dev.yml up -d

# Set required environment variables (dev values)
export DATABASE_DSN="postgres://postgres:dev@localhost:5432/agentplatform?sslmode=disable"
export REDIS_ADDR="localhost:6379"
export NATS_URL="nats://localhost:4222"
export VAULT_ADDR="http://localhost:8200"
export JWT_SECRET_OVERRIDE="dev-secret-minimum-32-chars-long"
export ENVIRONMENT="development"

# Run migrations, then start
psql "$DATABASE_DSN" -f scripts/001_schema.sql
go run ./cmd/server

Tests run the standard way, with the race detector on and a coverage option:

go test -race ./...
go test -race -cover -coverprofile=coverage.out ./...
go test -race ./internal/security/... -v

Load testing uses the k6 suite against a staging URL, and the repo ships scripts/smoke-test.sh, scripts/monitor-canary.sh, and scripts/chaos-test.sh for deployment verification. The production path is container-first: build the hardened image, deploy to staging, run smoke tests, then canary to production with automatic rollback if SLOs breach. Documented SLOs are strict — 99.99% availability and 100ms p99 for the gateway — which tells you this is designed against real production expectations, not demo thresholds.

Honest status and roadmap

Status: working, development-stage infrastructure. The Go code is substantive — the engine loop, RBAC matrix, circuit-breaking LLM gateway, HITL service, and NATS-backed audit service are all implemented and internally consistent. The security posture is thoughtfully layered rather than decorative.

Three honest qualifications. First, the gVisor agent sandboxing, Temporal orchestration, and WASM tool plugins appear in the architecture diagram and module descriptions as design targets; the verified Go code centers on the gateway, auth, agent loop, LLM gateway, HITL, audit, and browser-pool layers. Second, the README's license line reads "Proprietary. All rights reserved." while the repository itself is public on GitHub — a contradiction worth flagging to the maintainer. Third, the SLO table and multi-region deployment story describe a production ambition the single-repo code is still growing into; treat the k6 suite and canary scripts as the beginning of that verification, not the end.

A sensible roadmap from here: finish wiring the execution sandboxing named in the diagram (gVisor or an equivalent), build the reviewer UI the HITL service is clearly designed to feed, publish benchmark runs of the k6 suite to validate the SLO table, resolve the license contradiction, and harden the browser service's compliance proxy with the egress rules the README promises. What exists today is a strong, security-conscious foundation for agent infrastructure — the kind of skeleton that shows the author has thought about what can go wrong, which is the only credential that matters in this space.

Frequently asked questions

Is this production-ready?

The core Go modules are implemented and the architecture is production-minded (budgets, circuit breakers, immutable audit, dead-man's-switch HITL). Treat it as a strong development-stage foundation; the sandboxing layer and SLO validation are still ahead of it.

How does the dead man's switch work?

High-risk tool calls create a Review with an expiry time. If a reviewer approves, rejects, or edits the arguments, that decision stands. If nobody responds before expiry, the action is cancelled automatically — it is never approved by default.

Which LLM providers are supported?

The gateway fronts Anthropic, OpenAI, Google, and a local provider, with circuit breakers per provider and task-level token and cost budgets enforced by the agent engine.

What is the audit trail backed by?

NATS JetStream, wired directly in internal/audit/service.go, with the design intent of cryptographically chained events retained long-term in S3 with Object Lock.

The bottom line

Enterprise Agent Platform is what it claims to be in the parts that matter: a security-first agent infrastructure written in Go, with budgets, permissions, circuit breakers, human review, and immutable audit as first-class architecture instead of afterthoughts. It does not claim to be finished, and it is better for it. If you are evaluating open-source foundations for running autonomous agents with real consequences, this is a repo worth reading line by line — starting with internal/agent/engine.go, internal/auth/rbac.go, and internal/hitl/service.go.

Source: verified against the public repository github.com/Shivay00001/enterprise-agent-platform — module structure, engine, RBAC, LLM gateway, HITL service, and audit code read directly. Deployment-stage claims are the README's design targets, stated as such.