AI Agent Governance

AI agent governance is the discipline of controlling what an AI agent is allowed to do in production — which models it may use, which providers may handle which data, which tools it may call, who must approve sensitive actions, and what evidence exists that all of this happened within policy.

TramAI's position on agent governance is deliberately narrow and technical: runtime authority. Not governance consulting, not policy documents, not a dashboard bolted on after the fact — the enforcement boundary lives in the runtime that executes the AI workload.

Governance Is Not Authoring, Orchestration, or Observability

The term "agent governance" gets used for four different things. They are not interchangeable.

Concern	Question it answers	Typical home
Agent authoring	How do I build an agent that plans and uses tools?	Framework APIs, agent SDKs
Orchestration	How do I coordinate multi-step workflows, retries, and state?	Workflow engines
Observability	What happened?	Logs, traces, metrics
Runtime governance	What was allowed to happen, and who decided?	Policy engine inside the runtime
Governance evidence	How do I prove the system stayed within policy?	Audit stores, evidence artifacts

Most agent frameworks stop at the first two and treat the last three as somebody else's problem — usually a separate security stack bolted on later.

TramAI's premise is the opposite: for JVM backends, the governance boundary should be part of the runtime that executes the workflow, not an external layer.

What Runtime Authority Looks Like

In TramAI, "governed" is implemented as concrete, enforced mechanics:

Runtime policy enforcement — Allow, Deny, and RequireApproval decisions evaluated by a policy engine at mandatory enforcement points: before provider resolution, before provider invocation, before provider fallback, before tool exposure, before tool execution, before tool results are reinjected into the model context, before the response is returned to the caller, and before a suspended workflow is resumed. These are called from engine internals, not from an optional interceptor chain — no path reaches a provider or tool executor without passing the policy engine.
Controlled model and provider routing — explicit allowlists for models, providers, fallback providers, tools, and permissions. Nothing is permitted by default.
Trust zones — each provider is classified as LOCAL, EU_CLOUD, or GLOBAL_CLOUD, and data classification constrains which zones a request may reach. A RESTRICTED classification permits LOCAL routing only, with no fallback.
Tool permission policies — tools are governed at exposure and execution boundaries with ALLOW / DENY / REQUIRE_APPROVAL semantics. Exposure permission is not execution permission.
Human approval lifecycle — a tool execution can suspend itself, create a cryptographically bound approval challenge, and resume only when an external authorizer presents the correct token.
Data loss prevention — regex-based DLP interceptors redact sensitive data (PII, secrets) from model outputs and tool results before they reach consumers, parsers, or caches.
Hash-chained audit — every policy decision is recorded in a SHA-256 hash-chained event stream in which each event carries a sequence number, the previous event's hash, the enforcement point, decision, actor, and reason code. Retrospective tampering breaks the chain and is detectable.
Execution evidence — runtime evidence exporters turn real decisions into structured artifacts (policy.decision, tool.permission families), and evidence packs summarize deployment security posture for reviewers.

Agent Authoring and Orchestration Still Exist

Governance is not a replacement for building agents. TramAI keeps the developer layer first-class:

Typed @AiService contracts in Kotlin and Java with structured output as the default contract.
A standalone core with an optional Spring Boot adapter — framework-agnostic by design.
An optional orchestration module for multi-step workflows with steps, branching, parallelism, and gates.

The difference is that when a workflow step touches a model, a provider, a tool, or a fallback, it passes through a governance boundary instead of just a framework callback.

Available Today vs Roadmap

The distinction below matters. TramAI will not present roadmap functionality as shipped functionality.

Available today — shipped in 0.6.0:

Policy engine with Allow / Deny / RequireApproval decisions and PolicyConfiguration.secure() as the deny-by-default baseline
Sovereign profile (tramai.profile: sovereign): model/provider/tool/permission allowlists, trust zones, classification-aware routing, and STANDARD / OFFLINE deployment modes
Human approval with suspension, token-bound resume, cryptographic binding, expiry, replay-safe continuation, and lifecycle audit
DLP interception with audit emission
Hash-chained audit trail, policy.decision / tool.permission / approval.decision runtime evidence, and evidence packs for deployment attestation
One Spring Boot starter covering both profiles and a standalone runtime — dev.tramai:tramai-bom:0.6.0 aligns the versions

Not shipped in 0.6.0 (0.7.0 direction):

Control plane — the direction described as "AI governance and control plane for JVM workloads": inventory, policy, explainability, and intervention surfaces for viewing workflows, policies, approvals, and evidence across a deployment. Preview REST approval surfaces and a reviewer UI exist in the sovereign ops modules but are disabled by default; the full control plane is not released.

Stability boundary: 0.6.0 is a published release candidate of the sovereign runtime, not a stable 1.0 API. The sovereign store SPIs and approval gateway contracts are RC+ Stable; concrete store implementations, control planes, and internal APIs carry no compatibility promise. See API stability.

Governance Is Not Legal Compliance

Runtime governance produces technical controls and evidence. It does not produce legal conclusions.

TramAI can help you implement and evidence technical controls — logging, human oversight, model/provider registries, risk controls, audit trails, and incident history. TramAI does not provide legal advice, automatic legal classification, certification, conformity assessment, or guaranteed compliance with any regulation, including the EU AI Act. See EU AI Act technical controls for the boundary drawn in detail.

Why "Governed AI Workflows" Is the Right Category

"AI agent governance" is the broad category. "Runtime governance for AI agents" is the technical subcategory. TramAI sits at the intersection with a JVM specialization: runtime governance for AI workloads in Java and Kotlin systems.

Other frameworks can build and orchestrate AI workloads. TramAI specializes in governing their execution boundaries. That is the differentiation the rest of this site builds on:

Runtime governance — enforcement vs observability
Tool governance — ALLOW, DENY, REQUIRE_APPROVAL
Human approval — HITL as a runtime state transition
JVM AI governance — why Java/Kotlin teams need this in-process
EU AI Act technical controls — technical evidence, not legal claims

Sovereign Mode — the composed, fail-fast runtime profile
Approval Workflows — suspend/resume lifecycle in depth
DLP — data loss prevention
Evidence Packs — deployment attestation
Sovereignty overview — what sovereignty means operationally
Enterprise AI governance solution — fit scenarios for regulated teams
TramAI on GitHub