RWCX

Permissions and Control — What Is the AI Allowed to Read, Write, Change and Execute?

Capability Is Not Permission

Page 31 gave an agent a capability array: tools it could potentially use. Page 32 separated the different kinds of AI memory. Now another boundary becomes critical.

Being technically capable of an operation does not mean the system is authorized to perform it.

An AI model can generate a request such as “read this file,” “update this record,” or “run this command.” The actual operation is performed only if the surrounding software, credentials, permissions and control policy allow it.

RWCX — Four Useful Questions

These categories can overlap in real systems. RWCX is a HAAW reasoning tool—not a claim that every operating system or API implements exactly these four permission bits.

R — Read

Read permission controls what information can enter the working system.

Read-only access can still be powerful. An agent that can inspect logs, configuration, process state and network status may diagnose a problem without being allowed to alter anything.

And the model does not automatically “see” everything the tool can access. The tool must retrieve information and the surrounding system must make the relevant result available to the model.

W — Write

Write permission allows creation of new persistent or externally visible state.

Writing is a consequence boundary. Before the operation, the proposed output may exist only as generated text or structured arguments. After an authorized write, something outside the inference has changed.

C — Change

Change means altering state that already exists. It deserves separate attention because modifying an existing object can carry different consequences from creating a new one.

Deletion belongs here as a particularly important form of change. Some systems sensibly distinguish update, delete, rename and permission-management even more finely.

X — Execute

Execute means causing an operation to run.

Execution does not necessarily imply permission to modify everything the executing program can reach. The program itself runs under some identity and permission boundary.

The Model Does Not Hold the Master Key

This is one of the most important boundaries in an agentic AI system.

The transformer may produce a structured action request. The control layer can allow it, deny it, narrow it, request human approval or substitute a safer operation.

Return to the HAAW Web-Server Example

Our Page 31 agent was told:

Its effective permission profile could look like this:

The model may correctly infer that fixing a typo and restarting the service would probably repair the outage. That does not grant permission to do either.

Knowledge of an Action Is Not Authority to Perform It

A model can know how to do something while the deployed system gives it no mechanism or authority to do it.

This separates three ideas that casual language often collapses:

Identity Matters

Permissions are normally granted to some authenticated identity: user, service account, process, application, role or temporary credential.

The same tool may be read-only for one identity and read/write for another. An agent's practical capability therefore depends not just on its tool list, but on the credentials and policies attached to those tools.

Least Privilege

A strong design principle is to provide only the permissions required for the job.

This limits the damage possible from mistakes, misunderstood instructions, faulty tool arguments or compromised components.

Human Approval Is a Synchronization Point

Some operations can stop at an approval boundary:

The human is not merely “watching the AI.” The human can be an active control node in the dependency graph. Until approval arrives, the dependent action does not proceed.

Permissions Can Be Conditional

Real authorization is often richer than yes/no.

Sandboxing — Give It a Smaller World

Instead of trusting a process with the whole machine, a system can execute it inside a restricted environment—a container, virtual machine, sandbox, limited working directory or other isolation boundary.

The program can still execute, but the world it is capable of affecting is deliberately constrained.

Permission asks what an operation may do. Isolation limits what the executing environment can reach.

Audit — What Actually Happened?

Permission control is incomplete without records. For an important action we may want to know:

This leads directly back to WITNESS.

The WITNESS View of RWCX

For each consequential tool event, WITNESS should distinguish:

If the model requested a file deletion but authorization denied it, the evidence should say exactly that. “The AI deleted the file” would be false.

If the tool executed but returned an error, that is another distinct event. If execution succeeded but the expected state did not result, that too must remain visible.

RWCX and the Capability Array

Page 31's capability array becomes more precise when each capability carries permissions and conditions.

So an agent's real operating envelope is not simply “What tools does it have?” It is:

Which tools, acting as which identity, on which resources, with which operations, under which conditions?