Authorization

# Ground Authorization in your agent

## Objective
Use “Authorization” precisely in code, documentation, and conversations: An authorization defines permitted actions on a target; technical enforcement depends on account rights, tools and their environment.

## Prerequisites
- Inspect how the term is used today in the repository, documentation, and prompts.
- Identify the neighboring notions already named: Tool, Agent.
- Preserve existing correct usages.

## Working definition
An authorization defines permitted actions on a target; technical enforcement depends on account rights, tools and their environment.

## Decisive difference
A prompt instruction expresses a boundary but does not remove a technical right. A sandbox and an approval each have a scope to verify.

## Example that counts as Authorization
You authorize reading a copy and check that modifying it waits for approval before execution.

## Counter-example
“Be careful” does not configure the rights of a connector that can send messages.

## Acceptance criteria
- Every use of the term matches the working definition.
- Edge cases are settled with the decisive difference, not by intuition.
- Neighboring notions (Tool, Agent) are named with their own term.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The agentic vocabulary already used in the repository and documentation

# Map the neighboring notions

## Objective
Extend the same rigor to the related notions (Tool, Agent) so the project vocabulary stays coherent.

## Checks
- List every neighboring notion used without a definition.
- Apply its documented decisive difference.
- Record the still-ambiguous cases for the next entry.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:fa97c46e64e1bb4deed035d385092026e4b88075762b8c545d4762f9802d8d12

# Fix a mix-up around Authorization

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Compare the disputed usage with the working definition: An authorization defines permitted actions on a target; technical enforcement depends on account rights, tools and their environment.
- Apply the decisive difference: A prompt instruction expresses a boundary but does not remove a technical right. A sandbox and an approval each have a scope to verify.
- Confront the case with the documented counter-example: “Be careful” does not configure the rights of a connector that can send messages.

## Possible causes
- The term is used for a neighboring notion (Tool, Agent).
- The observed form (interface, script, service) is confused with the actual behavior.
- An alias (permission, access control) carries a different meaning in the project.

## Bounded fixes
- Rename or reclassify only the usages that contradict the working definition.
- Document each choice by citing the decisive difference.

## Final verification
- Reread every corrected occurrence against the documented example and counter-example.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The agentic vocabulary already used in the repository and documentation

# Anchor the vocabulary in the project

## Objective
Turn the clarification into a reusable rule so the mix-up does not return.

## Checks
- Add the working definition to the project glossary.
- Link every neighboring term to its own entry.
- Check new documents against the decisive difference.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:2b8258539de114684ca64b850a1ddbfc8920d93d341de263469d4773927e23c9