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 a single starter: tramai-spring-boot-starter auto-configures both runtimes, selected with tramai.profile:

dependencies {
    implementation(platform("dev.tramai:tramai-bom:0.6.0"))
    implementation("dev.tramai:tramai-spring-boot-starter")
    implementation("dev.tramai:tramai-spring-provider-openai")
}

@AiService interfaces become Spring beans with auto-configuration — no manual wiring, and @EnableTramai is not required.
tramai.profile: sovereign turns on fail-closed allowlists (tramai.sovereign.allowed-models, allowed-providers, allowed-tools, allowed-permissions, provider-zones, models); the same application code runs under either profile.
@AiTool beans are collected from the application context, and their security metadata (permission, risk, approval mode) drives policy evaluation.
Actuator, Micrometer, and OpenTelemetry surfaces come from the tramai-spring-boot-starter-sovereign-ops* modules; durable approval and audit stores from -sovereign-persistence-file / -jdbc.
Standalone mode remains available for non-Spring JVM applications (tramai-standalone plus a provider module).

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

0.6.0 is a published release candidate, not a 1.0 product: the sovereign store SPIs and approval gateway contracts are RC+ Stable, while the Spring auto-configuration for the Preview approval gateway and the REST control plane are Preview. Compare against API stability before you depend on a surface.

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.