Fullmakt Rails

Live, mock-adapter-backed. The Fullmakt Rails endpoints are callable today over both REST and the MCP server, but the Altinn integration behind them runs in mock mode pending live partner validation (BD-FULLMAKT-PARTNER). The response shape is identical in both modes. Nothing here is a legal guarantee.

Fullmakt Rails are Apier's authority layer for AI agents: the plumbing that lets a Norwegian company hand an AI agent a specific, bounded mandate to act on its behalf — and take it back at any time. "Fullmakt" is the Norwegian term for a granted authority or mandate. Instead of an agent holding a company's raw credentials, the company delegates a scoped authority through an Altinn systembruker (system user), and Apier acts within that delegation, never outside it.

The design goal is a delegation that is scoped (limited to named scopes, not blanket access), revocable (the company can withdraw it and the agent's authority stops), and auditable (every use is recorded). Apier brokers this through Altinn's authorization model — it does not invent a parallel one — so the authority an agent holds is the same authority a Norwegian company can grant, inspect, and revoke in Altinn itself.

Who Fullmakt Rails are for

• Enterprises that want an AI agent to handle a narrow, well-defined regulatory task (for example, preparing a filing) without giving the agent standing access to everything the organisation can do in Altinn.
• Agent developers building on Apier who need a first-class, machine-to- machine way to ask for an authority, check whether they currently hold it, and hand it back — without a human clicking through a portal on every run.

How it works

• Delegation lives in Altinn. The company grants a systembruker delegation; Apier reads and acts within it, never outside it.
• Rich Authorization Requests (RAR). The agent's access is expressed as a scoped RAR token bound to the customer org via the systembruker. Apier performs the Maskinporten on-behalf-of token exchange server-side and caches the token under an org-widened key, so a token minted for one company can never be reused for another.
• Access-package enforcement is fail-open. The access-package (tilgangspakke) gate on POST /api/v1/actions/execute denies only on a proven mismatch — a verified action→package mapping versus a delegation whose recorded packages provably lack it — and is flag-gated (FULLMAKT_PACKAGE_ENFORCEMENT, default off). Unknown or unverified state always allows, so a mapping gap never wrongly blocks a real authority. A live Altinn Policy Decision Point (PDP) verification is still pending; until it lands, Apier's own recorded delegation state is authoritative for its gating.

Endpoints

Live, mock-adapter-backed. All three endpoints are callable today. The Altinn integration behind them runs in mock mode pending live partner validation; the response shape is identical in both modes. Scope on every endpoint is the ACTIVE read:altinn, never the reserved delegate:* that keeps the raw system-user delegate route human-gated.

The Fullmakt tag in the OpenAPI spec carries the full request/response signatures for each operation.

MCP tools

The same three operations are callable over Apier's MCP server at /api/mcp, so an agent can broker, inspect, and revoke a fullmakt through the Model Context Protocol without hand-building a REST client. Each tool forwards to the live REST route above, is gated on read:altinn, and returns the standard MCP { result, justification, metadata } envelope:

• request_fullmakt → POST /api/v1/fullmakt/request — broker a delegation and bind an agent principal. A write tool.
• check_fullmakt → GET /api/v1/fullmakt/{org} — read your fullmakt state for a company (full / partial / none plus Norwegian fix-steps). A read tool.
• revoke_fullmakt → POST /api/v1/fullmakt/revoke — withdraw a delegation and retire its agent principal. A write tool.

request_fullmakt and revoke_fullmakt are the first agent-callable, discoverable write tools on the MCP surface; check_fullmakt is a read-only lookup of Apier's recorded delegation state (no live Altinn PDP call).

How it fits together (AGT-02)

Fullmakt Rails is the AGT-02 workstream — the authority layer that clears the legal blocker for agentic execution. An agent cannot lawfully act for a company without a delegation the company granted, can inspect, and can withdraw. The lifecycle is grant → act → revoke: request_fullmakt brokers the delegation and turns an agent identity (an agent principal) into an actor holding delegated authority; check_fullmakt confirms the authority is live before the agent acts; a binding action then runs through POST /api/v1/actions/execute behind the fail-open access-package gate; and revoke_fullmakt withdraws the authority when the engagement ends. Every request and revoke lands an immutable fullmakt.request / fullmakt.revoke audit-log row plus a provenance entry, joinable by correlation_id — the same forensic chain that backs binding filings — so an agent's whole authority lifecycle is reconstructable after the fact.

Status

Fullmakt Rails are live over REST and MCP, mock-adapter-backed pending live Altinn partner validation (BD-FULLMAKT-PARTNER). This page grows as the live integration lands; the concept, scopes, and the Altinn systembruker mechanism are documented here so the machine interface and the human interface do not drift.