Inspect another resource purpose
Compare skills, references, workflows, and advisory guidance.
Open this resource →Advisory rule explanation
Follow trusted context beyond the request.
Understand Backend boundary guidance through queued indexing, trusted customer scope, and checks across service handovers.
A request can be correct while later work loses its scope. Explore how the advisory rule helps an agent inspect that transition.
01 / Advisory rule explanation
Keep customer scope attached to the work
Search adds background indexing so a request can queue a document update. The request handler already knows which customer owns the document.
The worker runs later, outside the original request. If the queued work loses that context, a correctly authenticated request can still lead to incorrect data access.
Backend boundary guidance directs attention to this kind of handover. It is an advisory rule, not an implementation of authorization.
The fictional example concerns search-api. Use its questions to inspect your own service contract rather than copying an assumed authentication or queue design.
A trust boundary is a transition where less trusted input reaches a protected operation. A tenant identifies the customer or organization whose data is handled.
A syntactically valid document identifier establishes neither customer ownership nor permission. Follow how trusted context supplies those decisions in the actual service.
02 / Advisory rule explanation
Catalog identity for this example
| Catalog property | Recorded value |
|---|---|
| Published resource name | Backend boundary guidance |
| Catalog identifier | betterloop.safe-backend |
| Type | Advisory rule |
| Version | 1.0.0 |
| Maintainer | Betterloop platform catalog |
| Catalog state | Ready for selection |
| Company review state | Company approval is still required for release |
| Declared clients | Claude Code and Codex |
| Dependencies | None |
| Required configuration | No company-specific values are declared |
| Permissions | Selection supplies no extra authority |
03 / Advisory rule explanation
The rule’s intent, explained independently
External input needs validation before it influences a protected operation. Valid shape is only one part of that decision; authorized scope also matters.
Use authenticated and trusted service context to establish permissions. A caller-controlled field should not silently replace the context that authorizes the operation.
Carry that scope through reads, writes, caches, and background work. A correct request handler can still delegate to a path that drops the boundary.
Inspect failures and diagnostics as carefully as successful responses. Error handling should preserve useful information without exposing credentials or private records.
Respect existing public interfaces and repository contracts. A boundary repair can still break callers if it changes response semantics without examining them.
These paragraphs explain RULE.md in original editorial language. They are not literal resource instructions and do not change the underlying published rule.
04 / Advisory rule explanation
Trace an indexing request across the service
- 01
Identify the trusted context
Find how the service establishes the authenticated customer scope.
- 02
Inspect request validation
Check how document input becomes a validated service value.
- 03
Inspect the permission decision
Determine whether the authenticated caller may index the requested document.
- 04
Inspect the queued payload
Follow the identity and scope needed by the worker.
- 05
Inspect the worker access
Trace document reads and index writes under the intended customer scope.
- 06
Inspect error handling
Check what the service emits when a boundary check fails.
05 / Advisory rule explanation
Use one background task as the worked example
Suppose the request includes a document identifier and a desired indexing priority. The service must validate the priority without trusting a supplied customer identifier.
Trace the authenticated context to the permission decision. Then inspect how the approved work is represented in the queued message.
The worker should recover the trusted scope through the service’s existing design. This page does not prescribe an unverified queue format or token mechanism.
Practice indexing cases:
Permitted: an authorized request indexes its allowed document.
Outside scope: a request names a document owned by another customer.
Invalid input: the priority fails the documented validation rule.
Worker execution: the indexing write retains the intended customer scope.
Error path: diagnostics exclude credentials and private document contents.Check the final index or relevant data-access evidence when possible. A successful enqueue result alone does not establish what the worker later wrote.
If a queue or index cannot run locally, describe that missing observation. A source trace may establish important behavior while runtime execution remains unverified.
06 / Advisory rule explanation
Look for scope at every handover
| Service point | Evidence to inspect | Question it answers |
|---|---|---|
| Request parsing | Validated input and rejection behavior. | Can malformed input reach the protected operation? |
| Authorization | Trusted identity and permission evaluation. | May this caller act on this document? |
| Queue creation | The reviewed payload and its protected context. | Can the worker recover the intended scope? |
| Worker data access | Scoped reads and indexing writes. | Does later work preserve the customer boundary? |
| Cache behavior | Keys, namespaces, and invalidation paths where present. | Can one customer receive another customer’s derived state? |
| Diagnostics | Actual errors and emitted values. | Does failure reveal private data or credentials? |
07 / Advisory rule explanation
Choose checks that distinguish the boundary
Use an allowed case to establish the normal contract. Pair it with an outside-scope case that would expose a missing permission or tenant condition.
A validation case answers a separate question. Rejecting an invalid priority does not establish that a well-formed document identifier belongs to the caller.
When work is asynchronous, inspect the worker result as well as queue acceptance. Otherwise, the evidence ends before the sensitive operation occurs.
Inspect cache behavior only when the service actually uses a cache on this path. Do not invent infrastructure merely to expand the review checklist.
Observe error output under a representative failure. A comment promising redaction is weaker than the implemented error path and an inspected result.
Compare public response behavior with affected callers. Existing consumer expectations remain relevant even when a boundary correction is necessary.
08 / Advisory rule explanation
Use the advisory rule without mistaking its role
The selected entry supplies guidance. It does not enforce tenant isolation, install an authentication library, or provide a query wrapper.
Authorization still belongs in application code at the correct boundary. A resource selection cannot repair an unscoped worker operation by itself.
The rule grants no additional tools or external permissions. A diagnostic or publication action still needs the appropriate task authority and native access.
It also does not define a universal test command. Use the repository's own interfaces, fixtures, and contracts to examine the relevant service behavior.
For a frontend wording correction, this backend trace may be irrelevant. Keep the work aligned with the actual request rather than expanding into hypothetical services.
An exhaustive security assessment needs a defined audit process. This focused advisory rule is not a complete threat model or security certification.
09 / Advisory rule explanation
Evaluate whether selection improves the source trace
Confirm that betterloop.safe-backend 1.0.0 is available from the intended signed release. The catalog example declares no dependency.
Ask the agent to work on a bounded service change with a real trusted-context handover. Keep relevant worker and data-access code available.
Inspect whether the resulting explanation connects identity, permission, and scoped operations. A list of security terms without that relationship is weak evidence.
Compare claimed checks with the actual allowed, outside-scope, validation, and error observations. Keep unavailable worker or deployment environments explicit.
If the resource is missing, investigate selection and signed state. If the work ignores an existing boundary, inspect task applicability and the agent's reasoning.
Resource retrieval and safer implemented behavior are separate findings. Record both before deciding whether to adopt a revised resource version.
10 / Advisory rule explanation
Leave a service decision another developer can inspect
Summarize the actual boundary, its trusted context, and the operations examined. Include worker or cache paths only when they exist in the service.
Name any unverified handover before releasing the change. The next reviewer should understand where source evidence ends and runtime observation begins.
Keep private document values out of the handover. A bounded account of the path and result can be useful without reproducing customer content.
11 / Advisory rule explanation
Questions about the backend rule
Is valid input enough to permit the operation?
No. Validation checks shape and supported values. Trusted context and the service contract must establish authorization.
Does installing the rule make the worker tenant-safe?
No. The application needs correctly scoped operations and evidence from the relevant worker path. The rule supplies advice.
Should every backend task inspect every cache?
Inspect caches affected by the real service path. Avoid unrelated work that does not help establish the requested behavior.
12 / Advisory rule explanation
Take the example through your own review
The public explanation is a starting point for evaluation. Inspect the exact resource files selected by your company before accepting a configuration change.
Keep the catalog identity and dependency versions attached to that review. The reviewed release should supply the same content the owners examined.
Selection creates reviewable configuration content; it does not by itself approve or activate it. Follow the normal signing and team adoption process.
On the developer device, complete required native trust and session activation. Then examine resource retrieval and the representative task as separate observations.
A signed release establishes the reviewed content and scope. It does not guarantee that the native agent follows every instruction.
Use the approval workbook when the example requires additional operations. Resource advice and authority to execute a tool remain distinct decisions.