GDPR agent permission and delegated access architecture for enterprise LLM deployment — Reference Architecture

Reference architecture · published 2026-10-16 · regulated enterprise · GDPR · layout spec_first · implementation executed in CI before publish

Enterprise implementation parameters

Every value below is a parameter you can hold a vendor or an internal team to. Adjectives are not acceptance criteria.

The control that resolves this is an Intersecting Delegated Authority, evaluated before the request reaches a model provider rather than audited afterwards. In regulated enterprise the binding constraint is GDPR, and the question it actually asks is what is the lawful basis, and can you actually erase. The shape below holds p95 ≤ 600ms over REST over HTTPS, and ships with a standard-library implementation that runs as written.

Why this blocks production

The agent is given a service account so it can complete its work, and it now acts with more authority than any human who invokes it. An intern's request and an administrator's request reach the same powerful identity.

What GDPR specifically requires

GDPR asks two things an audit log does not answer: under what lawful basis was this processed, and can you erase it on request. Erasure is the harder one — a prompt embedded into a vector index and a fine-tune has propagated beyond the row you deleted.

The artifact that satisfies it is a lineage graph from source record to every derived artifact. The way teams most often fail it: an erasure request that cannot be honoured because the data survives in embeddings, caches and eval sets.

Implementation artifact — Delegated authority as an intersection, with expiry

Standard-library Python, no external dependencies, runs as written. Executed by the publish gate: if it raises, this page does not ship. Wire it behind REST over HTTPS; the failure mode it guards against is a retried POST creating a duplicate record. The output you hand the assessor is the data-subject lineage and erasure report.

"""Delegated authority: an agent never exceeds the user it acts for.

The failure: an agent is given a service account so it can "do its job", and it
then acts with more authority than any user who invokes it. Correct delegation
is an intersection — the agent may do only what BOTH its own grant and the
invoking user permit — and it must be time-boxed, because a standing delegation
is a standing privilege.
"""
from dataclasses import dataclass


@dataclass(frozen=True)
class Grant:
    subject: str
    permissions: frozenset
    expires_at: int

    def valid(self, now: int) -> bool:
        return now < self.expires_at


class DelegationError(PermissionError):
    pass


class DelegatedAuthority:
    """Effective permissions = user ∩ agent grant, never a union, and never
    the agent's own service identity."""

    def __init__(self):
        self.users: dict[str, frozenset] = {}
        self.grants: dict[str, Grant] = {}
        self.audit: list[dict] = []

    def define_user(self, user: str, permissions: set) -> None:
        self.users[user] = frozenset(permissions)

    def delegate(self, agent: str, permissions: set, expires_at: int) -> Grant:
        g = Grant(agent, frozenset(permissions), expires_at)
        self.grants[agent] = g
        return g

    def effective(self, agent: str, user: str, now: int) -> frozenset:
        g = self.grants.get(agent)
        if g is None:
            raise DelegationError(f"no grant for agent {agent!r}")
        if not g.valid(now):
            raise DelegationError(f"grant for {agent!r} expired")
        if user not in self.users:
            raise DelegationError(f"unknown principal {user!r}")
        return g.permissions & self.users[user]

    def authorise(self, agent: str, user: str, action: str, now: int) -> bool:
        try:
            allowed = self.effective(agent, user, now)
        except DelegationError as exc:
            self.audit.append({"agent": agent, "user": user, "action": action,
                               "allowed": False, "reason": str(exc)})
            return False
        ok = action in allowed
        self.audit.append({"agent": agent, "user": user, "action": action,
                           "allowed": ok,
                           "reason": "" if ok else "outside the intersection"})
        return ok

    def chain(self, agent_a: str, agent_b: str, user: str, now: int) -> frozenset:
        """A delegating to B cannot widen authority — chaining intersects
        again, which is what stops escalation through a hop."""
        return self.effective(agent_a, user, now) & self.grants[agent_b].permissions


if __name__ == "__main__":
    da = DelegatedAuthority()
    da.define_user("analyst", {"read_reports", "read_pii"})
    da.define_user("intern", {"read_reports"})
    da.delegate("summariser", {"read_reports", "read_pii", "delete_records"},
                expires_at=100)

    assert da.authorise("summariser", "analyst", "read_pii", now=1) is True
    # The intern cannot read PII, so neither can an agent acting for them.
    assert da.authorise("summariser", "intern", "read_pii", now=1) is False
    # Nobody granted delete to a user, so the agent's own grant cannot supply it.
    assert da.authorise("summariser", "analyst", "delete_records", now=1) is False

    eff = da.effective("summariser", "intern", now=1)
    assert eff == frozenset({"read_reports"}), eff

    # Expiry is enforced, not advisory.
    assert da.authorise("summariser", "analyst", "read_reports", now=101) is False
    assert "expired" in da.audit[-1]["reason"]

    # Chaining must not widen authority.
    da.delegate("exporter", {"read_reports", "export"}, expires_at=100)
    chained = da.chain("summariser", "exporter", "analyst", now=1)
    assert chained == frozenset({"read_reports"}), chained
    assert "export" not in chained, "chaining widened authority"

    assert da.authorise("unknown_agent", "analyst", "read_reports", now=1) is False

    print("Delegated authority intersection: OK")
    print(f"  audit entries {len(da.audit)}, "
          f"denials {sum(1 for a in da.audit if not a['allowed'])}")

The GDPR control, as code

Article 17 erasure propagated into derived artifacts. This is the artifact an assessor asks for under GDPR specifically — it is not the same control as the one above, and a system that implements one does not thereby implement the other. It executes under the same publish gate.

"""Article 17 erasure that propagates into derived artifacts.

The erasure request everyone implements is a DELETE on the source row. The one
that fails an audit is the derived copy: embeddings in a vector index, a cached
retrieval chunk, a fine-tuning corpus, a prompt log. Article 17(2) expects
controllers to take reasonable steps to inform processors of the erasure, and a
vector built from personal data is still personal data.

So erasure is modelled as a lineage walk with a receipt per derived artifact,
and the request is not complete until every downstream store confirms.
"""
from datetime import datetime, timezone


class Store:
    def __init__(self, name: str, kind: str):
        self.name, self.kind = name, kind
        self.rows: dict[str, dict] = {}
        self.erased: list[str] = []

    def put(self, key: str, subject_id: str, payload: str) -> None:
        self.rows[key] = {"subject_id": subject_id, "payload": payload}

    def erase_subject(self, subject_id: str) -> int:
        doomed = [k for k, v in self.rows.items() if v["subject_id"] == subject_id]
        for k in doomed:
            del self.rows[k]
            self.erased.append(k)
        return len(doomed)

    def holds(self, subject_id: str) -> int:
        return sum(1 for v in self.rows.values() if v["subject_id"] == subject_id)


class ErasureOrchestrator:
    """Lineage-aware erasure. A store that is not registered cannot be erased,
    so registration is the control — an unregistered derived store is exactly
    how personal data survives a 'completed' erasure."""

    def __init__(self):
        self.stores: list[Store] = []
        self.lineage: dict[str, list[str]] = {}

    def register(self, store: Store, derived_from: str | None = None) -> Store:
        self.stores.append(store)
        if derived_from:
            self.lineage.setdefault(derived_from, []).append(store.name)
        return store

    def execute(self, subject_id: str) -> dict:
        receipts = []
        for store in self.stores:
            held = store.holds(subject_id)
            removed = store.erase_subject(subject_id)
            receipts.append({"store": store.name, "kind": store.kind,
                             "held": held, "erased": removed})
        residual = {s.name: s.holds(subject_id) for s in self.stores
                    if s.holds(subject_id)}
        return {
            "subject_id": subject_id,
            "completed_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
            "receipts": receipts,
            "residual": residual,
            "complete": not residual,
            "derived_stores_covered": sorted(
                s.name for s in self.stores if s.kind != "source"),
        }


if __name__ == "__main__":
    orch = ErasureOrchestrator()
    src = orch.register(Store("crm_postgres", "source"))
    vec = orch.register(Store("vector_index", "embedding"), derived_from="crm_postgres")
    cache = orch.register(Store("retrieval_cache", "cache"), derived_from="vector_index")
    logs = orch.register(Store("prompt_log", "log"), derived_from="crm_postgres")

    src.put("c-1", "subject-77", "Jana Soor, contract renewal notes")
    vec.put("v-1", "subject-77", "[0.11, -0.4, ...]")
    cache.put("k-1", "subject-77", "chunk: contract renewal notes")
    logs.put("l-1", "subject-77", "prompt containing the same notes")
    src.put("c-2", "subject-90", "unrelated subject")

    result = orch.execute("subject-77")
    assert result["complete"], result["residual"]
    assert len(result["derived_stores_covered"]) == 3, result
    assert sum(r["erased"] for r in result["receipts"]) == 4, result
    assert src.holds("subject-90") == 1, "erasure must not over-reach"

    # An unregistered derived store is the failure this design exists to expose.
    orphan = Store("analytics_extract", "warehouse")
    orphan.put("a-1", "subject-77", "same personal data, different copy")
    assert orphan.holds("subject-77") == 1
    assert orphan.name not in {s.name for s in orch.stores}

    print("GDPR Article 17 lineage erasure: OK")
    print(f"  stores erased {len(result['receipts'])}, complete={result['complete']}")
    print(f"  UNREGISTERED store still holding data: {orphan.name} "
          f"({orphan.holds('subject-77')} row) — registration is the control")

The request path

Intersecting Delegated Authority — the request path, with the decision points that must exist before the first model call:

flowchart LR
    USER[Invoking user<br/>entitlements] --> INT{Intersect}
    GRANT[Agent grant<br/>time-boxed] --> INT
    INT --> EFF[Effective permissions]
    EFF --> ACT{Action in effective set?}
    ACT -->|no| DENY[Deny + audit reason]
    ACT -->|yes| DO[Execute as the user, not the agent]
    EFF --> HOP[Delegate to agent B] --> INT2{Intersect again} --> EFF2[Narrower still]

Implementation components

1. Principal entitlements — What the human may do, from the system of record.
2. Agent grant — What the agent may ever do, scoped per task.
3. Intersection at call time — Effective = user ∩ grant, computed per request.
4. Time-boxed grants — Expiry enforced, so delegation is not standing authority.
5. Chain intersection — Agent-to-agent delegation intersects again; a hop cannot widen.
6. Denial audit — Every denial recorded with the reason — the escalation signal.

Risk and control matrix

Each row carries an acceptance parameter rather than an adjective, because "low latency" cannot be signed off. Retention here is bound by per the data class retention schedule, enforced automatically.

Review questions and answers

• A data subject requests erasure. Trace exactly what gets deleted, including embeddings and cached completions.
  Every derived artifact carries the source record id, so erasure traverses the lineage graph. The completion report lists each store touched and the rows removed.
• If an intern invokes the agent, can it read data only an analyst may see?
  No. Effective permissions are the intersection of the agent's grant and the intern's entitlements, so anything the intern lacks is unavailable regardless of the agent's own grant.
• What authority does the agent have when nobody has invoked it?
  None that matters. The grant is time-boxed and only becomes effective when intersected with an invoking principal, so there is no standing authority to borrow.
• Can agent A delegate to agent B and end up with more permissions than A had?
  No. Chaining intersects again, so each hop can only narrow the set. Widening through a hop is the escalation path this design exists to close.
• How quickly does a revoked entitlement take effect for an in-flight agent?
  Within the entitlement cache TTL, which is bounded by the revocation SLO. The stale-grant window is documented rather than assumed to be zero.
• What is recorded when an agent attempts something outside its effective set?
  The agent, the invoking user, the attempted action and the reason for denial. Repeated denials are the signal that something is probing for authority it does not have.

See also

• Part of enterprise ai compliance architecture.
• This pattern also governs GDPR provider failover and degradation architecture for enterprise LLM.
• This pattern also governs GDPR cost control architecture for enterprise LLM deployment.
• The same control appears in GDPR tracing and token accounting architecture for enterprise LLM.
• GDPR vendor evaluation criteria for enterprise AI implementation applies the same mechanism under a different obligation.
• If this is the blocker in front of you: enterprise AI infrastructure review.