Operations & reference

Operate with evidence.

Audit & governance

Governance you can prove.

Regulators and auditors want to know who allowed an agent to act, and to see proof. Fort answers both by default, from records you hold in your own cloud.

Allowed and denied calls are recorded in a hash-chained ledger. The record connects the agent’s identity, the policy decision and any human approval. Evidence can be verified independently, offline.

Controls for common agent risks

Human oversight. Records you hold.

Fort is designed to support the oversight and record-keeping work security teams do around frameworks such as the EU AI Act, NIST AI RMF, ISO/IEC 42001 and OWASP, and Japan’s AI Promotion Act, AI Guidelines for Business (METI/MIC) and FSA AI Discussion Paper.

These are governance contexts, not claims of certification or automatic compliance. Ready-made control maps and evidence packs are coming soon.

Your first agent

Put an agent in Fort.

Fort runs the agent you already have. Package it as a container image, declare it in your policy repo, and apply. Fort gives it its own sandbox, its model access and only the tools its policy allows.

1. Package the agent as a container image.Any OCI image, such as one built with Docker, in a registry Fort can reach. Pin it by digest, so every change to the agent’s code is a reviewed change.
2. Declare it in your policy repo.Declare the agent’s image, command, network-capable programs and providers. Separately declare each tool-server image, backend secret references and health check, then grant the agent access to its tools.
3. Create the project and register credentials.Use fort project create first, then register the model provider and backend tool secrets. Model keys and backend credentials stay outside the agent.
4. Review and apply.fort policy diff shows what would change. fort apply starts the agent in its own sandbox.
5. Verify the complete tool path.Confirm the tool server is healthy and the agent’s MCP client uses Fort’s injected URL. Make one allowed, read-only call to the backend and check its decision in the ledger.

# Your policy repo
fort.yaml
projects/sre/
  project.yaml
  agents/sre-agent.yaml        # the agent shown above
  tool-servers/ops.yaml
  rulesets/ops-read.yaml

# Create the project, register model and tool credentials, then apply
fort project create sre --wait
fort provider add anthropic --project sre --api-key-file anthropic.key
fort tool secret set sre/ops-kube-token --from-file ops-kube.token
fort policy diff
fort apply
fort agent get sre/sre-agent

This layout is illustrative: supply your actual images, complete policy files, backend settings and credentials. Configure the agent’s MCP client to use the injected tool URL. Fort deploys the tool-server images in separate containers on the same VM; onboarding finishes when a permitted call reaches the backend.

Coming soon

What comes next.

The following capabilities are planned and are not presented as available features.

• Model and runtime attestation, provenance, and trust and risk scoring.
• Prompt-injection and anomaly detection, and vulnerability scanning.
• Secure agent-to-agent communication.
• Ready-made control maps and evidence packs.