AI posture

AI posture and agent-native access

fremforge is AI-agnostic by design. The forge’s job is to be a clean, API-first, standards-compliant Git server that interoperates with whatever AI tooling your team picks. We do not ship a forge-integrated AI product. We do not plan to.

For the bring-your-own-key AI integrations that fremforge does ship — PR review, Renovate explanations, the customer-callable /ai/complete endpoint — see Admin → AI integrations for the supported vendor list (Anthropic, OpenAI, Azure OpenAI, Mistral, Vertex Gemini, or any OpenAI-compatible URL) and the configuration walkthrough.

Bring your own AI

Whatever your developers run today operates against fremforge unchanged:

Claude Code, works against any Git remote and any documented REST API. Point it at a fremforge repo and it operates the way it would against GitHub.
Cursor, uses the standard Git workflow. Editor config carries over.
Windsurf, same.
Codex CLI, same.
Aider, same.
Continue, Cody, etc., IDE-side AI tools that operate at the file level pick up fremforge through the standard Git remote.

There is nothing to configure on the fremforge side for any of these. The forge sees AI-driven Git operations as it sees human Git operations: pushes, pull requests, issue comments, API calls. The AI vendor relationship is yours, not ours.

Why we made this choice

Three reasons, each of which we go into depth on in the launch post on the fremverk blog:

Decoupling matters for sovereignty. Customers who reject US-hyperscaler Git for CLOUD Act reasons have the same reasons to reject AI vendors whose model hosting is under the same jurisdiction. Making the AI decision orthogonal to the Git decision lets every customer compose their own posture.
Enterprise AI is converging on a single vendor per organisation. Most enterprises standardise on one AI platform across all tools. Forcing a second AI vendor through the forge is friction nobody asked for.
Sophisticated AI coding has moved off the forge UI. It is in the IDE (Cursor, Windsurf), the CLI (Claude Code, Aider, Codex CLI), and the editor extension (Continue, Cody). The forge UI is for collaboration and operations, not for the AI loop.

What we do ship: a first-class API for agents

The other half of AI-agnostic is making sure fremforge is excellent to consume from AI tooling. Three near-term commitments and one Phase 3+ direction:

Every admin UI action has a public API endpoint

The fremforge admin UI is a client of the public REST API, with no admin-only endpoints and no surprise gaps. AI coding agents that need to provision orgs, manage seats, configure policy, read findings, or initiate exports do so against the same surface as the humans.

OpenAPI spec at a stable URL

The machine-readable specification lives at /api/openapi.yaml. AI tooling that consumes OpenAPI specs (MCP-aware frameworks, OpenAPI-driven client generators, agent toolkits) can load it directly.

Agent-identity OAuth flow on the Phase 2 roadmap

Today, agents authenticate against fremforge using personal access tokens issued by a human user, or OAuth client credentials registered with the organisation. This works for any integration today.

In Phase 2 (driven by real customer demand rather than a speculative roadmap) we ship the explicit agent-identity flow:

OAuth 2.0 client credentials with an on-behalf-of claim, the agent authenticates as the agent, acting on behalf of a named user, under a scoped delegated mandate.
Audit-log distinction, agent actions are recorded with actor=agent:<agent_id>, on_behalf_of=<user_id>. The audit-stream filter in the admin UI separates agent actions from human actions for compliance and incident review.
Scoped, time-boxed delegated mandates, a user can mint a narrow token for an agent (“can add up to 3 seats, valid 24h”, “can read findings only, valid 1h”), bounded by the user’s own role. An agent holding a Member-role mandate cannot change policy because a Member cannot.
Reference implementation, a Claude Code (or Cursor / Codex) example that provisions a new fremforge org end-to-end from a user-issued mandate. Fully documented, fully runnable. Marketed as “the first EU Git host your AI can buy for you.”

The endpoints are already documented in the OpenAPI spec ahead of implementation, marked with the x-fremforge-phase: 2 extension so consumers can filter accordingly.

MCP server (Phase 3+)

Phase 3 work: a Model Context Protocol server for fremforge that exposes admin actions and Git operations as first-class MCP tools for any MCP-capable runtime. MCP is a neutral protocol; adopting it means we do not pick an AI vendor by picking a client library. Consistent with the AI-agnostic stance.

What this means for buyers in 2026 and 2027

A prediction we are willing to stake the product on: forge-level AI integration becomes a procurement question the same way data residency became one in 2020. Compliance and security teams will start asking where does the inference happen, who processes the embeddings, does training telemetry include customer code. Vendors whose AI is inseparable from their core product will be making the case one way; vendors whose AI is optional and user-selected will be making it another.

fremforge is positioned on the answer side that we think will age better. BYO AI is not a compromise; it is the architectural stance that will still be right in 2028 when half the current integrated AI offerings have pivoted, been acquired, or been priced out of reach.

Get help

Questions about agent-mandate scope, OpenAPI patterns for specific agent frameworks, or whether a specific integration model is supported: email support@frem.sh with subject line starting AI -.