Fullmakt Rails
Brokered, scoped, revocable authority (fullmakt) that lets a Norwegian company delegate a specific mandate to an AI agent through an Altinn systembruker, designed for machine-to-machine acting. Live over REST and MCP, mock-adapter-backed pending live partner validation.
[Cite this as: Apier.no Docs v0.1.0 — last updated 2026-10-15]
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. The response shape is identical in both modes. Nothing here is a legal guarantee.
No sandbox mirror. Fullmakt Rails has no
/api/v1/sandbox/route: the MCP tools returnSANDBOX_TOOL_UNAVAILABLEunder the synthetic sandbox bearer, and the REST routes need a real API key holding thefullmakt:writescope (chosen at key creation; the defaultread:*key cannot broker, create or revoke). Request and revoke act on one of your own agent principals (agent_principal_id), which you create withPOST /api/v1/fullmakt/principals. A principal is a label you declare for one of your agents, not a verified identity: it becomes an actor only once a fullmakt is brokered onto it and the company approves it in Altinn.
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.
- Maskinporten token. The delegation request itself uses Apier's own
scope-based Maskinporten token, because asking a company to approve a
systembruker is the vendor's action, not an action on the company's
behalf. Reads made under an approved delegation (today: the company's
Altinn filing history) request a per-organisation systembruker (RAR)
token bound to that company. That live read path stays in mock mode
until the
altinn:instances.readscope is active on Apier's production client; nothing here describes a live Altinn read today. - Access-package enforcement is fail-open. The access-package
(tilgangspakke) gate on
POST /api/v1/actions/executedenies only when a verified action→package mapping shows that the recorded package is missing, 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. Apier's recorded delegation state is provisional data for this local check, not a confirmation from Altinn of which access packages the company holds.
Endpoints
Live, mock-adapter-backed. All four 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. The three write operations (create a principal, request, revoke) take the assignable
fullmakt:writescope, which a key opts into at creation; the read side stays on the ACTIVEread:altinn. Neither is the reserveddelegate:*that keeps the raw system-user delegate route human-gated. None of them has a sandbox mirror.
| Endpoint | Method | Purpose | Scope |
|---|---|---|---|
/api/v1/fullmakt/principals | POST | Create an agent principal: the consumer-declared identity a fullmakt is brokered onto (display_name, optional intended scopes; starts pending, unbound). | fullmakt:write |
/api/v1/fullmakt/request | POST | Broker a scoped delegation and bind it to an agent principal (write-once; a pending principal becomes active). | fullmakt:write |
/api/v1/fullmakt/{org} | GET | Read which of your agent principals hold live authority for a customer org, and which scopes are still missing. | read:altinn |
/api/v1/fullmakt/revoke | POST | Withdraw a delegation and flip its agent principal to terminal revoked (revoke-by-insert on the append-only delegations table). | fullmakt:write |
The Fullmakt tag in the OpenAPI spec
carries the full request/response signatures for each operation.
MCP tools
The request, status and revoke 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 (principal creation is REST-only today). Each tool forwards to
the live REST route above, is gated on the route's scope (fullmakt:write
for the two write tools, read:altinn for the read tool), 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/noneplus 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. 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.
How do I configure an MCP client for Apier's tool catalogue?
Client-by-client setup for Claude, Cursor, VS Code, and the OpenAI and Azure agent runtimes, a five-minute quickstart, and the full 26-tool reference.
Endpoint reference
Apier.no API contract, with the authoritative machine-readable spec at /openapi.json and browsable per-endpoint docs grouped by capability.