Enterprise ChangeOps

A private AI-assisted control plane that analyzes cross-system changes, enforces exact-plan approvals, executes bounded actions, and preserves complete audit and rollback evidence.

Comment

Inspiration

Enterprise changes rarely stay inside one system. A small API or schema update can silently break CRM mappings, analytics pipelines, support workflows, and downstream integrations.

We built Enterprise ChangeOps to answer a practical question: How can organizations use AI to understand cross-system impact while keeping execution deterministic, reviewable, and safe?

Our goal was not to let an AI agent make unrestricted production changes. Instead, we designed a governed control plane where agents gather evidence and propose actions, while application code enforces policy, approvals, identity, execution limits, auditability, and rollback behavior.

What it does

Enterprise ChangeOps manages a change from discovery through verified execution:

  1. A change event is authenticated and accepted.
  2. A seven-agent Google ADK fleet analyzes dependencies, compliance requirements, and affected enterprise systems.
  3. The deterministic workflow coordinator creates a bounded remediation plan.
  4. A human operator reviews and approves the exact plan hash, version, scope, and environment.
  5. The Tool Gateway validates identity, policy, approval, resource scope, and idempotency before executing registered tools.
  6. Bounded changes are applied to synthetic CRM, analytics, and support systems.
  7. Verification evidence, retries, failures, rollback activity, and audit events are preserved.

The Control Tower provides one interface for changes, workflows, agents, approvals, security posture, tool registrations, and audit evidence.

Production writes are hard-disabled in the current managed sandbox.

How we built it

Enterprise ChangeOps is a polyglot, cloud-native system built with:

  • Next.js and TypeScript for the Control Tower
  • Python, FastAPI, and Pydantic for the control-plane services
  • Google ADK for the bounded specialist-agent fleet
  • Cloud Run for ten private managed services
  • Firestore for durable changes, workflows, approvals, idempotency, and audit records
  • Pub/Sub for change-event delivery, retries, and dead-letter handling
  • Secret Manager for application credentials
  • Google-signed ID tokens for keyless service-to-service authentication
  • Artifact Registry and Cloud Build for private container builds
  • Docker Compose and emulators for reproducible local development

The deployed services use separate service accounts and least-privilege IAM relationships. No Cloud Run service allows unauthenticated access.

We also preserve application-level authorization while authenticating private Cloud Run transport. Google identity tokens use X-Serverless-Authorization, while application bearer tokens and signed webhook credentials remain independent.

Challenges we ran into

One major challenge was combining Cloud Run identity with existing application authorization. Using the normal Authorization header for both layers would overwrite the application identity, so we implemented a separate keyless platform-authentication layer.

During live browser acceptance testing, Next.js correctly rejected Server Actions forwarded through the authenticated local proxy because the browser origin and managed host differed. We fixed this using a narrow allowed-origin configuration for localhost only.

We also discovered that PowerShell secret creation had appended a newline to a callback credential. HMAC-based flows still worked because both sides used identical bytes, but the credential could not safely travel in an HTTP header. We corrected the secret-generation process, rotated the affected secret, and verified callback recovery.

Finally, repeated demonstrations mutate the synthetic in-memory enterprise systems. We made this boundary explicit and kept durable workflow and audit data separate in Firestore.

Accomplishments that we're proud of

  • Deployed and authenticated 10 private Cloud Run services
  • Implemented seven bounded specialist agents
  • Enforced exact-plan human approval before execution
  • Preserved deterministic policy and execution outside the AI layer
  • Added tenant isolation, idempotency, bounded retries, dead letters, verification, and rollback
  • Used keyless service identities with no service-account key files
  • Kept production mutations hard-disabled
  • Built an authenticated checker that verified all ten services as ready-private
  • Completed a real browser-driven managed workflow from event ingestion through approval, tool execution, verification, and audit evidence

What we learned

AI is most useful in enterprise change management when it helps collect evidence, identify impact, and construct proposals—not when it bypasses deterministic controls.

We learned that transport identity, application identity, approval authority, and execution policy must remain separate. We also learned that end-to-end browser and cloud verification reveals integration failures that unit tests alone cannot expose.

Most importantly, “the model recommended it” is not sufficient evidence for a production change. Every action needs a traceable plan, policy decision, human approval when required, bounded tool contract, and durable audit record.

What's next for Enterprise ChangeOps

Next, we plan to:

  • Add GitHub-triggered deployments using Workload Identity Federation
  • Replace the always-running Pub/Sub pull subscriber with a request-driven managed consumer
  • Add durable managed backing stores for demonstration enterprise systems
  • Integrate real enterprise connectors behind explicit production enablement
  • Add richer change-diff visualization and approval comparisons
  • Expand policy packs, rollback strategies, observability, and operational alerts
  • Support additional change sources such as CI/CD, schema registries, and service catalogs

Built With

Share this project:

Updates

Submission history