TramAI - governed AI workflows for Java and Kotlin

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.

ConcernQuestion it answersTypical home
Agent authoringHow do I build an agent that plans and uses tools?Framework APIs, agent SDKs
OrchestrationHow do I coordinate multi-step workflows, retries, and state?Workflow engines
ObservabilityWhat happened?Logs, traces, metrics
Runtime governanceWhat was allowed to happen, and who decided?Policy engine inside the runtime
Governance evidenceHow 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 six enforcement points: before provider resolution, before provider invocation, before provider fallback, before tool exposure, before tool execution, and before tool results are reinjected into the model context.
  • 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, making retrospective tampering 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 (current release line):

  • Policy engine with Allow / Deny / RequireApproval at six enforcement points
  • Sovereign profile: model/provider/tool/permission allowlists, trust zones, classification-aware routing, offline deployment mode
  • Human approval with suspend/resume, cryptographic binding, and expiry
  • DLP interception with audit emission
  • Hash-chained audit trail and runtime evidence exporters
  • Evidence packs for deployment attestation
  • Spring Boot starter and standalone runtime

Planned for TramAI 0.7.0 and beyond (roadmap 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 today but are disabled by default; the full control plane is not released.

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:

Related Documentation