perimeter@enterprise :~$ policy eval --stream

The Perimeter

Enterprise operating system for AI actions.

The model proposes. The Perimeter decides. The decision is deterministic.

Abstract

The Perimeter is a control layer between AI agents and enterprise systems — SAP, Microsoft 365, SharePoint, databases, internal APIs. Every tool call an agent proposes is authorized deterministically against the requesting user's own permissions before it reaches a system of record: allowed, denied, or held for human approval, in under two milliseconds, and recorded in an append-only log against exactly one identity. The model proposes; the platform decides. This page states the problem, the architecture, and where the implementation stands.

Keywords — deterministic authorization · MCP · SAP · Microsoft Graph · principal propagation · audit

1Problem

Enterprise AI demos work in week two, then stop. Never because the model is bad.

They stop because nobody can answer four questions: if this agent reads SharePoint, does it respect the permissions the user already has, or does it surface the salary folder to a working student? Which tools is it allowed to execute at all? Who is accountable when it writes to SAP? What does the auditor get shown?

Those questions are not model problems. They are authorization problems, and they are unsolved between systems.

2Architecture

One control plane in the request path. Nothing reaches company data without passing through it.

  AI AGENTS                     ENTERPRISE SYSTEMS
  Copilot, custom, MCP          SAP S/4HANA
       │                        Microsoft 365 · SharePoint
       │  tool call             Databases · internal APIs
       ▼                                     ▲
  ┌───────────────────────────┐              │
  │  THE PERIMETER            │  scoped      │
  │                           │  credential  │
  │   identity   who asks     ├──────────────┘
  │   policy     may they     │  executes as the
  │   approval   human gate   │  user, with the
  │   trimming   what returns │  user's own
  │   audit      what ran     │  permissions
  └───────────────────────────┘
       │
       └──▶ append-only log · hash-chained
            one identity per action

Figure 1 — Request path. The gateway holds identity, policy, approval, trimming and audit; the agent holds none of them.

The AI never decides what it is allowed to do. That decision is ours, it is deterministic, and it is made outside the context window — where a prompt injection cannot argue with it.

3Decision procedure

→ tool      CreatePurchaseOrder
→ principal agent:procure-bot/7f1c (SPIFFE)
            on-behalf-of j.weber@acme (Procurement)
→ args      vendor=DE-4471  amount=480.00 EUR

  role in Procurement ................ true
  amount < threshold(500) ............ true
  manager sign-off ................... true

ALLOW  1.4ms  executes as j.weber, not as a service account

─────────────────────────────────────────────────────────

→ args      vendor=DE-4471  amount=12400.00 EUR

  amount < threshold(500) ............ false

HOLD   1.2ms  approval → m.keller · escalates in 72h

─────────────────────────────────────────────────────────

→ tool      SearchDocuments  q="compensation 2026"

  4 hits · 3 removed by security trimming

ALLOW  2.0ms  returns only what j.weber was already cleared
              to see. Salary folder was never in the set.

Listing 1 — Three calls, one user, one policy set. The verdict and its latency precede the explanation, as they do in the log.

Same inputs, same answer, every time — whichever model is on the other end, whatever the prompt says.

4Design primitives

IDENTITY: OIDC federation to the customer's IdP — we never become one. One cryptographic identity per agent instance, so twenty parallel agents are twenty distinct principals in the log.
AUTHORIZATION: Deterministic policy on every call, evaluated in-process, sub-2ms p99. Not a classifier. A 98%-accurate guardrail in front of an ERP write is a 2% chance of a wrong purchase order.
PROPAGATION: Token exchange to a scoped downstream credential carrying both principals. SAP executes as the business user; Graph applies its own trimming. No fat service account to impersonate from.
APPROVAL: Human in the loop as a durable workflow, not a request. An approval waits three days, escalates, and survives a deploy.
AUDIT: Append-only, hash-chained, signed, timestamped. Shaped to EU AI Act Art. 12. Live observability and cold compliance evidence off one emission path.

5Implementation

data plane      Go · spec-compliant MCP server · OAuth 2.1
                Resource Server (PKCE/S256, DCR, RFC 8707)
policy          Cedar — formally verified core, statically
                analyzable. Rust validates and signs the
                bundle; cedar-go evaluates it in-process.
                Official conformance suite runs in CI.
identity        SPIFFE/SPIRE JWT-SVID · RFC 8693 exchange ·
                SAML bearer to SAP · on-behalf-of to Graph
relationships   SpiceDB (ZedToken consistency)
approvals       Temporal durable workflows
state / audit   Postgres · hash-chained · KMS-signed ·
                RFC 3161 timestamps
transport       NATS JetStream — customers won't run Kafka
telemetry       OpenTelemetry, single emission path
deploy          Helm on Kubernetes · single-tenant · air-gap
models          model-agnostic by design; we compete on
                trust, not model quality. Model choice is
                itself a policy decision — pin a data
                classification to a model and a region.

Table 1 — Stack. The load-bearing choice is splitting Cedar validation from evaluation: Rust validates and signs the bundle at compile time, cedar-go evaluates it at request time.

6Related work

Identity vendors give an agent an identity. They are not in the request path with the semantics of a purchase order, so they cannot answer "may this agent call CreatePurchaseOrder for €480 on behalf of this user right now."
AI gateways govern the call to the model — cost, rate limits, PII in the prompt. We govern the call to SAP. Different side of the agent.
Guardrails are probabilistic classifiers on prompts and outputs. Detection, not authorization.
Vendor-native governance: Microsoft governs Microsoft, SAP governs SAP. Our customers run both plus twenty internal systems, and the gap is exactly in between.

The hard part was never the policy engine — that's a solved primitive, we use one. The hard part is permission-model translation: mapping SAP authorization objects and derived roles, SharePoint ACLs, sensitivity labels and Graph scopes into one decision model, per user. Grinding, unglamorous connector work that only comes from being inside real tenants.

7Status

BUILD: Prototype. First usable version targeted within a month.
BACKGROUND: Two years full-time inside enterprise SAP and Microsoft 365 tenants — 20+ paying clients, 200+ companies interviewed across DE / CH / AT / HU / ES. We hand-built this layer bespoke more than once. The Nth time you rebuild the same thing, it's a product.
MARKET: DACH industrial first — because it's the hardest, not the easiest. Data residency, works councils, on-prem, the world's densest SAP install base. A product that satisfies a German works council and an ISO auditor is over-qualified everywhere else.
CUSTOMER ZERO: Every coding agent that touches our own staging enterprise systems runs through The Perimeter, with its own identity, its own policy, and an entry in the same audit log we sell.

8Contact

Design partners: one department, one connector, one agent use case. We onboard you ourselves.

simon.bunyatov@aiphase.de