Adding Agent Governance Without Rewriting Human Access

The authorization envelope is useful only if it can be connected to the access policies that already protect enterprise resources. This chapter examines the proposed compositional overlay and the runtime controller around it. The central design judgment is whether an organization can add a constrained agent path while preserving the human permission path, then enforce both through a current, auditable decision point.

Preserve the human policy, add an agent branch

An enterprise rarely starts with an empty authorization system. Documents already have viewers and editors. Repositories already have owners, maintainers, or writers. Workspaces and folders already inherit permissions through their own hierarchies. Replacing those rules with a new agent-specific model would create a second source of truth and invite inconsistencies.

The research framework takes a different approach. It treats the existing domain policy as the base and overlays fresh relationships for agents, sessions, scopes, and delegation. For a selected human permission—such as viewing or editing a resource—the composed policy keeps the original human userset and adds a separate agent branch. That branch succeeds only when the agent is both in a compatible scope and connected through a delegation chain to a human who holds the underlying permission.

This is called a non-deleting overlay because the composition does not remove the original domain relations. A human who could access the resource before the overlay retains that path. The new branch is an additional route for an agent, but it is not a shortcut around the human-facing policy. If no human permission exists at the root, the agent cannot manufacture one by being delegated.

That preservation property matters for migration. It means an organization can begin with the permissions it already understands and add agent governance where agent access is needed. The overlay does not require every existing resource rule to be rewritten as an agent rule. It does require the organization to choose which domain permissions are eligible for agent lifting and which human relationship serves as the root for each one.

Imagine an enterprise that already governs documents and repositories through different systems. The document system may decide that a person can view a folder through direct sharing or inherited membership. The repository system may decide that a person can write to a project through team membership or ownership. The overlay does not claim that these permissions are identical. It creates an agent path for each selected relation and requires the corresponding human relationship as the root. A document reader can therefore inherit only the document-view branch, while a coding agent can inherit a repository-write branch if the human permission and delegation terms support it.

This is a more conservative migration than creating a shadow “agent role” that contains every permission a user has. A shadow role is convenient because it avoids connecting each action to its source, but it makes scope and revocation coarse. The overlay preserves the domain’s granularity. It can lift viewing without lifting editing, and it can attach different delegation or scope conditions to different resource relations. The cost is that the organization must decide which relations are safe to lift and maintain those mappings as the domain policy changes.

The construction has conditions. The names and types introduced by the overlay must be distinct from the domain’s existing principals and relations. The root expression used for delegation must be well typed and limited to human principals. It must not be more permissive than the original permission.