Policies, audit and RBAC

The last nine lessons were about one agent on one machine. A company has hundreds of developers, several agent products, contractors and shared credentials, and nobody can sit next to each of them. To make agent use governable, the rules must be written down, applied by something other than goodwill, split by role, and recorded in a way that survives disagreement. That is policy, role-based access control (RBAC) and audit.

Policy: a floor and stricter additions

A policy says what agents may do, in terms a machine can check: which tools, which agents, which command shapes, and what happens on a match. A useful structure has two layers.

• A baseline for the whole organisation, with a mode: observe (record and flag, enforce nothing), advisory (matches produce an approval decision) or enforce (matches produce a deny).
• Overrides (the baseline-plus-override pattern) for individuals or teams that can only add restrictions or choose a stricter mode. They cannot loosen the baseline.

That second rule is least privilege applied to the policy itself: the baseline is a floor, so one person cannot lower it for convenience. Beam's documentation describes exactly this shape, with owners, administrators and security managers able to manage policies, and overrides that "cannot loosen the organization baseline". It also describes presets for common shapes (git pushes, recursive deletes, elevated privileges, downloaded shell scripts, credential file references, outbound uploads) and advises starting in observe mode, validating on a test device, then tightening.

The rest of the documentation is a model of honest caveats, and worth copying into your own:

• An enforce decision depends on the installed client, the agent's version and the hook event; it must be verified in your target assistant. Claude Code and Codex can receive a deny before the action; others currently get a note.
• A missing or expired cached policy does not enforce these rules (the fail-open choice from lesson 9).
• Custom detection rules add findings; they do not become blocking rules.
• Policies are "not an operating-system sandbox", and a dashboard policy version is configuration evidence, "not proof that every endpoint has synchronized or denied a call".

Roles: who may change what

RBAC means permissions are attached to roles, not to individuals, and people hold roles. Two principles matter more than the details:

1. Least privilege. A role gets only what its job needs. Most people only need to connect their own device and see their own activity.
2. Separation of duties. The person who sets policy should not be the only person who can audit it. Beam's role set shows one way: owners and administrators manage settings and policy; a security manager investigates activity, reviews risks and manages policy and registered devices; an auditor inspects activity and can export the audit log, read-only; billing sees usage only; members connect personal devices. Security managers can read the audit log but do not hold export permission, a deliberate split.

Two implementation points from the same documentation are generally true of any RBAC: authorization is checked on the server ("hiding or showing a navigation item is not the authorization boundary"), and invitations and shared links are credentials and should be treated that way.

Audit: what it proves

An audit log is a record of who did what, when, to what. Two kinds matter here, and they answer different questions: the administrative log (who changed a policy, a role or a risk review) and the agent activity record (what the assistants proposed). Beam's documentation keeps them apart: "A risk review or reopening is an administrative event. An agent's tool proposal is activity evidence."

It is equally careful about weakness. The application does not expose audit update or delete operations, but "a database administrator can alter the backing records", and the implementation "does not provide WORM storage or database-enforced immutability". Exports are bounded (up to 5,000 matching records per export), intent may be logged before an external operation and the outcome after, and a missing outcome "does not prove that dispatch failed". An audit export "can support a review; it does not by itself establish regulatory compliance or successful endpoint enforcement."

Hold both facts. An audit log is the thing that lets you reconstruct events and hold actors to account, and it is evidence a cooperative adversary or a gap can weaken. Strengthen it with a tamper-evident design: store exports and chain heads somewhere the people being audited cannot edit.

The agent as an identity

Microsoft's October 2026 announcement, summarised in Beam's post, proposes treating agents as insiders: each agent gets its own identity separate from the user who sponsors it, so logs can tell what a person did from what an agent did; permissions are scoped to the task and time-bound; high-impact actions can require verified human approval; agents do not call any tool they find. The post notes that no dates were given, so it is direction, not a shipping control. The idea, though, applies today with whatever you have: separate machine identities for agents and CI from human accounts, no shared API keys on laptops, and short-lived credentials.

A rollout checklist

Beam's enterprise rollout checklist turns the level into steps. In order:

1. Inventory. Which agents, which data classes at risk, and what "done" means for phase one.
2. A small agent allowlist. Often two. Sprawl breaks hooks, SSO and evidence.
3. Identity. Enterprise accounts and SSO, seat review, and no pasted production keys or shared API keys.
4. Default-deny MCP and plugins, with version pins and a pre-connect scan.
5. Sandbox defaults and scoped credentials, per lessons 6 to 8.
6. Policy in observe mode first, then advisory, then enforce for the shapes you have validated.
7. Audit and review. Decide who looks at findings, how often, and where exports are kept.
8. Stop and recover. The NIST, NSA and CISA guidance, summarised in Beam's post, asks for tested ways to pause or terminate agent activity, revoke credentials and preserve evidence in advance.

The checklist also states the limit that this whole level has been circling: monitoring and logs are evidence, not certification, and "SSO proves who can open the product; it does not prove what" the agent does afterwards.

How AI changes this

Governance is the least glamorous part of AI security and the part that decides outcomes. What is new is the volume and speed of actors: agents multiply the number of identities and the rate of actions beyond what humans can review, and they can edit their own surroundings unless policy keeps that out of reach. Attackers target the governance layer itself (disabling monitors, rewriting settings), as lessons 3 and 9 showed. Defenders can use models to summarise audit trails and propose policy from observed behavior, which is helpful if a human approves the result. The old rules still anchor everything: least privilege, separation of duties, tamper-evident records.

Try it

This lab models a policy where overrides can only tighten, and a hash-chained log that reveals editing. It uses only Python and in-memory data. Save as gov.py.

import hashlib, json

MODES = ["observe", "advisory", "enforce"]
baseline = {"mode": "advisory", "blocked_tools": ["web_fetch"], "blocked_patterns": ["git push"]}

def effective(base, override):
    mode = max(base["mode"], override.get("mode", base["mode"]), key=MODES.index)
    return {"mode": mode,
            "blocked_tools": sorted(set(base["blocked_tools"]) | set(override.get("blocked_tools", []))),
            "blocked_patterns": sorted(set(base["blocked_patterns"]) | set(override.get("blocked_patterns", [])))}

print(effective(baseline, {"mode": "observe"}))
print(effective(baseline, {"mode": "enforce", "blocked_tools": ["shell"]}))

log = []
def add(actor, action, target):
    prev = log[-1]["hash"] if log else "0" * 64
    e = {"actor": actor, "action": action, "target": target, "prev": prev}
    e["hash"] = hashlib.sha256(json.dumps(e, sort_keys=True).encode()).hexdigest()
    log.append(e)

def verify():
    prev = "0" * 64
    for e in log:
        body = {k: e[k] for k in ("actor", "action", "target", "prev")}
        if e["prev"] != prev or hashlib.sha256(json.dumps(body, sort_keys=True).encode()).hexdigest() != e["hash"]:
            return False
        prev = e["hash"]
    return True

add("ana", "policy.update", "mode=enforce")
add("bo", "role.change", "carl -> auditor")
print("intact:", verify())
log[0]["target"] = "mode=observe"
print("after editing the first entry:", verify())

The first override tries to loosen the mode and is ignored; the second tightens it. Editing an old log entry breaks verification. Now find the weakness: if you can edit an entry, can you also rewrite every later hash so the chain still verifies? Yes, which is why the final hash must be stored somewhere the editor cannot reach. Write down who would hold it in your organisation.

Check yourself

Next

That completes the level on how agents are attacked and defended. In the next level you apply it to a real deployment, starting with threat modelling an agent deployment.