Whose Pump Is Botie Allowed to Inspect?

Botie now asks for an allowed tool: read_manual. The request contains a real asset ID, and the service can find a record for it. There is still a problem. The record belongs to a different customer.

We cannot settle that by asking Botie whether the caller seems trustworthy. The service needs the identity established by login and the permissions attached to that identity. Then it must compare those permissions with the particular object being requested.

Build separate tenant, asset and operation comparisons. Then change the stored asset’s tenant without changing its visible ID.

allow this operation

Authentication establishes which account is making the request, under the assumptions of the login system. Authorisation decides what that account may do. A signed-in technician may read manuals for assigned assets and still be unable to create jobs or access another site.

The service should derive the principal from the verified session or token, not from a field Botie supplies. Here principal means the application’s representation of that caller. Our small dictionary stores a tenant and two grant lists. A real application may query a policy service or database instead.

A model-generated role such as administrator has no effect on the authenticated principal.

Our service stores P7 under tenant north. A caller from north still needs a grant for P7. Checking the tenant alone would grant access to every asset in that organisation. Checking only the short ID would confuse two tenants that both use P7.

In the workshop, Match the tenant and Check this asset grant are separate components so their results remain visible. In a database, a scoped query can require both tenant and object ID before it returns the row. Keep a clear policy for objects shared across tenants rather than quietly removing the tenant condition.

The example’s policy denies cross-tenant access. Sharing would require an explicit additional rule.

The operation list contains read. A request to export, delete or schedule has no matching grant and is denied. That is a default-deny policy: absence of permission does not become permission. Missing or malformed principal fields must also fail the check.

Use exact identifiers from a controlled operation vocabulary. Substring matches are dangerous here: read is contained in some longer names without meaning the same operation. An unchecked wildcard can expand a narrow role into authority over future capabilities.

This is a deterministic decision over server records. A second language model is unnecessary.

records = {("north", "P7"): "North pump manual", ("south", "P7"): "South pump manual"}
caller_tenant = "north"
requested_id = "P7"
print(records.get((caller_tenant, requested_id)))
print(records.get((caller_tenant, "P8")))

North pump manual
None

Hiding an export button or removing a tool from a model prompt helps guide normal use. Neither prevents a caller from reaching an exposed service route another way. The service that reads or changes the asset must enforce the policy for each request.

For writes, keep the authorisation decision and the relevant state change together closely enough that an intervening ownership or permission change cannot silently invalidate the check. A database transaction, version comparison or policy revision check may be needed. The right mechanism depends on where those records live.

This is the reason to test the handler directly, without a model or the website interface in the path.

A maintenance assistant that only reads manuals should use a scoped read capability. It should not receive a general database administrator credential or an unrestricted command runner. Credentials belong in the service environment and should stay out of model-visible arguments and results.

The application must account for both the user’s authority and the service’s own authority. A powerful service account does not mean every user who can ask Botie a question may exercise all of its permissions. Check the caller before using that service account on their behalf.

Least privilege makes a mistaken request less consequential, while per-request authorisation decides whether that request may proceed.

An approved inspection for P7 does not authorise an inspection for P8. Preserve the action identity, arguments and revision that the reviewer saw, then compare them again at execution time. Recheck the reviewer’s current authority and the caller’s current access when your policy requires it.

Approval and authorisation answer different questions. A permitted caller may still need a human decision for a consequential write. A human saying yes does not give the application permission to cross a tenant boundary. Keep both checks in the execution path.

The earlier approval workshop supplied an exact-action match. This lesson adds the object-access boundary around that action.

A denied caller should not receive the protected manual inside an error message. Depending on the application, even revealing whether an asset exists may disclose information. A consistent external response can hide that distinction while a protected audit record retains the internal reason.

Test a permitted read, another tenant’s matching ID, an unassigned object in the same tenant, and a forbidden operation. Add a case where permissions change before execution. These cases catch different mistakes; one successful read says little about the deny paths.

The construction is correct only if it preserves the permitted case while closing the gaps exposed by the changed records.