Spring AI Governance

Spring AI solves a real problem: integrating AI into Spring applications. It brings model clients, prompt templates, and increasingly agentic execution into the Spring ecosystem.

This page is about the question that comes after integration: who governs the Spring AI workload once it runs in production?

Spring AI solves AI integration and increasingly agentic execution. TramAI focuses on the governance boundary around production AI workloads.

The Gap Between Integration and Governance

Spring AI makes it easy to call a model from a Spring bean. That is integration. Governance is a different set of questions:

Which models may this application call at all?
Which provider may handle restricted data — and what happens on fallback?
Which tools may the model call, and who approves the risky ones?
What is the audit record when a tool call is denied or approved?
What evidence exists that the workload stayed within policy?

Spring AI does not answer these questions as a primary design goal — it is an integration and agentic-execution framework. That is not a criticism; it is a division of labor. Integration frameworks build the workload. A governance boundary controls it.

How TramAI Complements Spring AI

TramAI is not a replacement for Spring AI's model abstractions or Spring's dependency injection. The two are complementary:

Concern	Spring AI	TramAI
Model integration	ChatClient, prompt templates, model adapters	Runtime governance boundary
Tool calling	Tool registration and execution	ALLOW / DENY / REQUIRE_APPROVAL at exposure and execution
Human oversight	Not built-in	Durable approval lifecycle with suspend/resume
Data classification	Not built-in	Classification-aware routing and trust zones
Provider control	Configuration-driven	Explicit allowlists, trust zones, governed fallback
Audit and evidence	External logging	Hash-chained audit events, runtime evidence exporters

What Governance Questions to Ask of Any Spring AI Production Workload

Before a Spring AI agent touches production data or tools, ask:

Allowlists — is there an explicit list of allowed models, providers, and fallback providers, or can the application call anything configured?
Trust zones — can restricted data only reach providers you designate, and is fallback constrained to those zones?
Tool permissions — what happens when the model calls a tool that deletes records or creates payments? Is the decision made at runtime, or is it a convention?
Approvals — is there a durable, auditable human gate for high-risk tool calls, or does the application "ask" in the prompt?
Evidence — can you reconstruct, per execution, which policy decisions were made and who approved what?

If the answer to several is "we rely on the model behaving", the workload is governed by convention, not by control.

TramAI and Spring Boot

TramAI integrates with Spring Boot through its own starter and sovereign starter — the governance boundary runs in the same Spring context as the application:

Spring-style @AiService contracts with auto-configuration.
The sovereign starter collects TramaiTool beans from the application context.
Actuator surfaces for worker health and ops (in the sovereign ops modules).
Standalone mode remains available for non-Spring JVM applications.

The governance layer does not require abandoning Spring AI. The realistic adoption path is: integrate with Spring AI or TramAI's typed contracts, then add the governance boundary around the execution.

A Note on Comparison Framing

TramAI is not positioning itself as "better at everything". Other frameworks can build and orchestrate AI workloads — that is their strength. TramAI specializes in governing execution boundaries. The strategic distinction is not feature-by-feature superiority; it is a different problem being solved. For the same reason, this page does not claim Spring AI cannot be secured — only that runtime governance is not its primary design focus and typically requires external integration.