Who Set the Permission Mode?

Imagine you maintain a community library's events page. The Saturday opening time is wrong in two places. You ask an A I assistant to prepare the correction. Two lines, one draft, no publication. Then it proposes opening another website.

You expected that permission request to come to you. Your colleague says the assistant can approve safe requests itself. The administrator says the organization requires approval. All three of you may mean something different by approval. The library still opens at ten.

The meeting about the setting may run until eleven. This is a fictional scene. No library system was tested. But it gives us a concrete question for this week. Before you hand over the task, who, or what, is allowed to say yes?

Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are my opinions and are not representative of any organization.

One additional disclosure as the Desk evolves. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability. I will not discuss nonpublic work here. These are my personal views, and they do not represent the State of Oregon or any other organization.

Opening music

Welcome back to A I Change Desk. I am Michael. It is Monday, November second, twenty twenty-six. This is episode fifty-two: Who Set the Permission Mode? Last time, we asked what changes after the conference. The useful answer started with a better experience for somebody.

This week, keep that person in view. Our library visitor wants the right opening time. We are looking at the permission choices behind that result. On October twenty-sixth, GitHub announced generally available assisted permissions in its command-line assistant, Copilot app, and Visual Studio Code.

A language model assesses requests involving commands, files, and addresses. Requests judged clearly safe can proceed automatically. That is not the same as a person approving them. Two days later, GitHub announced a connected cloud experience. It describes continuing a cloud session across supported interfaces, including a phone, browser, and development tools.

The rollout began with paid plans. Availability in your particular account still needs checking. That makes the permission question easier to encounter in ordinary work. You might start a correction while walking between meetings, then review the draft at your desk.

You remember the task, but do you remember its boundaries? Moving between screens does not itself prove those boundaries changed. It is a reason to make them visible. For listeners who do not write code, a command-line assistant is operated through typed commands.

The practical issue travels beyond that interface. When software can act, something decides whether it may proceed. Sometimes that is a person clicking approve. Sometimes it is a fixed rule for a narrow operation. Sometimes a model is asked to assess the request.

Those choices place different work in different hands. Here is the distinction to keep for the whole episode. A task request, an approval decision, and an enforced boundary are three different things. There can be a useful trade here.

You may want a routine local read to proceed without interrupting somebody who is reviewing a difficult change. You may want an external transfer to wait every time. The work is to make that division explicit, then find out whether the system implements it.

Our fictional library team has agreed on the outcome. They have also agreed that publication stays with a person. But prepare a correction might involve reading a supplied example, writing a draft, checking a website, or submitting a change.

An everyday instruction can conceal several separate decisions. Start there, before debating which mode sounds most responsible. List the work you intend to delegate. Keep the final publication decision visible. Then inspect the mechanism that handles each request.

There is a fact question we need to keep open. As checked for this November second edition, two GitHub documentation pages describe managed ask rules differently. These are centrally configured rules for requesting permission. The assisted-permissions guide says some eligible command-line ask requests can be approved by a model rather than a person.

The enterprise reference table describes fresh human approval. The guide also says enterprise deny rules still apply. We have not reconciled the client and version scope. We have not tested the runtime behavior. This is a documentation discrepancy, not a demonstrated bypass.

That distinction matters to the library team. If publication depends on a person saying yes, the word ask cannot settle who must do the approving. The immediate action is to preserve the uncertainty. Record the client, version, rule, and behavior your task requires.

Seek clarification from the product or platform owner. An isolated trial may help, if separately authorized and properly bounded. Do not turn an unresolved sentence into a live experiment. There is a useful new-session detail in the enterprise reference.

Its default-mode setting governs the starting mode for new sessions. That is not evidence of the effective mode in every session. For our fictional team, imagine two printed session records. One describes a newly started session. The other describes a session resumed from yesterday.

For this exercise, give them different permission modes. These are invented records, not claims about product behavior. The administrator points to the first record. The operator points to the second. They have been discussing different sessions for ten minutes.

Both have brought documentation. Neither has brought the same question. So write the session identifier beside the proposed task. Now everybody can discuss the same work. The answer may eventually be that the configuration is appropriate. It may be that the proposed task needs a narrower setup.

Either conclusion is more useful than winning an argument about a label that means different things to different people. Now put yourself in the operator's chair. You have a small correction and other work waiting. You would welcome fewer interruptions for routine steps.

You would also like the final page to remain unpublished until you have checked it. Those are compatible requirements if the boundaries are clear. The easiest mistake is to treat the task as one large permission decision. Approve the assistant, then assume all its intermediate choices fit inside what you meant.

Our fictional team separates the work into four possibilities. Read the supplied sample page. Write a proposed correction in a scratch copy. Open a web address found inside the page. Send the corrected page to a publishing service.

The first two are candidates for a bounded later trial. The third requires an explanation of why it is necessary. The fourth stays outside this exercise entirely. Nobody is choosing a live permission mode in this episode. Notice what this buys the conversation.

The team can discuss a useful amount of independence without giving the assistant responsibility for the whole service. They can also reject an unnecessary action without rejecting assistance with the original task. A developer might reasonably object here.

If every small step requires another meeting, the correction will take longer than doing it manually. That is a real cost to include. So do not count approval prompts as your success measure. Count whether the right decisions reach the right person, with enough context to make those decisions well.

A prompt that says only allow this action may transfer responsibility without transferring understanding. For the library example, a useful explanation would identify the exact page being read, the draft being changed, and whether anything can reach a public destination.

The reviewer should see why an extra website is needed. If nobody can explain that extra step, the team can remove it from the proposed workflow. There is also a recipient cost to remember. A correct draft that never reaches its human publisher has not corrected the visitor's information.

An automatically published mistake creates a different failure. The permission plan needs a handoff that somebody can finish. That is the continuity from last time. Keep the visitor's experience as the outcome. Use the permission design to support the work that gets the right information to that visitor.

This is where the second signal helps. On October twenty-seventh, NIST published initial agent-identity design tenets. That is the National Institute of Standards and Technology. These are proposed principles, not a new binding rule. Two ideas matter for today's question.

Separate the system that reasons about a task from the systems that control access to resources. Keep rule-determined access decisions primary; probabilistic assessments can inform them without becoming the primary mechanism. That does not make every model-assisted review prohibited.

Nor is this a NIST finding about GitHub. Task approval and resource access are related but different layers. We should not pretend a blog post resolves a product dispute. Here is my application to our fictional library. The assistant might suggest publishing because the correction looks obvious.

That suggestion is a statement about what would be useful. The publishing service still needs its own answer about who is allowed to change the public page. Think of a temporary helper at the front desk. They can notice an incorrect sign and prepare a replacement.

That does not automatically give them the building's master key. Good judgment about the sign does not establish key ownership. The awkward question is not whether the helper means well. It is whether the setup requires us to depend on the helper choosing not to use excessive access.

For a later, authorized trial, our team would want a scratch environment with no route to public publishing. Then a persuasive explanation cannot create that missing route. That is a proposed design requirement, not a tested configuration. There is a tradeoff worth admitting.

Separate environments and explicit handoffs take effort to maintain. If copying the draft back creates errors or delay, that cost belongs in the review too. The answer is not to pretend the cost disappears. It is to compare a small, bounded preparation task with a larger delegation you can actually support.

Maybe drafting two corrected lines is enough for now. You do not have to delegate the whole service to get useful help with one part of it. Our third signal comes from Google Cloud's semantic-governance documentation. The name refers to evaluating actions against natural-language policies.

The feature is still in preview. Google cautions that its model-based verdicts can be wrong. The guide was updated October thirtieth; that update date is not a feature launch date. The guide separates matching a proposed action to user intent from enforcing the resulting policy decision.

In its dry-run setting, verdicts are logged, but the policy engine does not block the actions. This is a different product from GitHub's permission system. It does not resolve the GitHub documentation discrepancy. It gives us another question for our own review: what does the system actually do with its judgment?

Suppose our fictional team receives a printed result saying that an outside request should be denied. The result looks reassuring. Then the facilitator reveals another field: observation only. In this invented example, the result did not enforce a block.

Keep the judgment and the enforcement behavior together. A record of what should have happened cannot establish what was prevented. The phrase dry run deserves particular care. It can sound as if nothing consequential will execute. That is not what this documented Google setting promises.

Observing a policy decision is not an isolated environment. This is why today's exercise stays on paper. A future trial needs its own bounded environment, permitted actions, and owner before anything executes. The worksheet cannot supply those protections by itself.

Think about the operator reviewing a screen at speed. They need the answer to fit in ordinary language. This check evaluated the request. This setting determined whether the check could stop it. This separate evidence shows what the action actually did.

If one of those pieces is missing, label it missing. Do not fill the gap with the most reassuring interpretation. And do not let a tidy conversation transcript substitute for evidence of an action outside the conversation. An invented transcript saying correction complete tells our team what the assistant reported, not whether a publisher received anything.

For each consequence, decide what evidence would settle that question. Use invented records today, not visitor details or private logs. Any later evidence collection needs an access and retention decision. More information is useful only when it resolves a question you are responsible for answering.

Here is a forty-five-minute block you can use with an operator and the person responsible for the system. If that person is unavailable, mark their decisions pending. Another attendee cannot quietly approve on their behalf. The output is a proposal for an authorized trial.

It is not permission to change settings or run one. Use paper, a blank document, and invented records. No accounts, live customer data, or external requests are needed. Before starting, make a tiny practice pack. An invented page shows nine o'clock in two places.

A separate reference says the correct time is ten. Add a card saying outside request denied, observation only. Add another saying correction complete, transcript only. Label every piece fictional. For the first ten minutes, define one service task.

Use our library example if it is useful. Prepare a corrected scratch copy for human review. No publication, no messages, and no changes to real files. Name the person who benefits: a visitor planning Saturday. Choose what correct means before you inspect any result.

Both Saturday times match the supplied reference of ten o'clock. Other dates and wording remain unchanged. The reviewer can identify the exact proposed changes. There is a tempting shortcut here: improve the whole page. Better headings, a new calendar, maybe a different booking form.

Those may be worthwhile ideas, but they are different tasks. Keep them in a separate list rather than expanding this one. For the second ten minutes, separate the approval decisions. Who may authorize reading the supplied sample? Who may authorize writing the scratch correction?

Who owns a change that reaches the public? The first two are candidates for the bounded proposal. Publication remains outside it and belongs to a named person. An outside address mentioned in the sample is unnecessary. Do not visit it to make the exercise more convincing.

Write the required behavior beside each action. Do not write only approved. Write who or what may make that decision, and where a person must remain involved. For the third ten minutes, describe the proposed setup. Return to our two fictional session records.

One is new; the other has been resumed. Give them different modes for discussion, clearly labeled invented. Choose which record your proposal concerns. Leave spaces for the client, version, account role, effective permission mode, applicable rules, and owner of those rules.

Record the environment and the resources it could reach. Write unknown wherever you lack evidence. A model name alone does not answer these questions. For the fourth ten minutes, describe the evidence you need. Include a proposed action that should not proceed.

The unnecessary outside request is our paper example. What would distinguish a recorded objection from a real block? What would establish that the intended scratch correction was made? Now reveal the observation-only card. It records a denial but does not demonstrate prevention.

Reveal the transcript saying correction complete. List which action questions that transcript cannot settle. Those are gaps to resolve in a separately authorized trial. They are not invitations to send an actual request now. If someone suggests using a live system for convenience, write that suggestion down as a new decision requiring approval.

Do not let the meeting drift into execution. Use the last five minutes for the handoff. Is the proposal complete enough for its authorized owner? It needs a defined task and expected result, a bounded environment, required permission behavior, and suitable evidence.

It also needs somebody who can review the correction and separately decide what happens after the trial. Where the disputed GitHub ask behavior is essential, hold the proposal until that question is resolved for the client and version you actually intend to use.

Assign one next action, owner, and date to each gap. The result may be ready for review, revise, or hold. None of those labels certifies a product safe. They tell the next person what decision is needed. If there is no agreed owner, the proposal stays incomplete.

That is a useful result from forty-five minutes. You have found the missing decision before creating a dependency. Return to the library's opening time. The desired result is modest and observable. A visitor sees the right Saturday hours, after a person reviews and publishes the correction.

Assistance can make the preparation easier. It can also introduce choices about reads, writes, web access, and who approves the next action. Those choices deserve names before they become habits. This week's practical move is to take one task and identify the permission mechanism in the session that matters.

Keep the request, the approval, and the enforced boundary distinct. Preserve any gap that you have not yet resolved. Then ask the authorized owner for the next bounded decision. Bring a concrete proposal, a useful outcome, and a visible limit.

The visitor should not need to understand your permission settings. The team operating the service should. I am Michael. This is A I Change Desk. I will see you next time.

Closing music