A valid token still needs permission

Imagine a small team receives a daily report from an automation worker. Nobody wants to upload it by hand each morning. They also don't want the worker to delete yesterday's reports or wander through another team's records.

M7 Identity gives the worker its own machine identity. A valid token intended for the report service helps establish who is calling. The report service still decides whether that caller may submit this report.

That distinction makes useful automation easier to trust: a known caller, doing a defined job, within limits the receiving service controls.

Start with the receiver's list

M7 principal lists can include machine application principals alongside a defined pool of people. For our example, the report service uses an incoming list to recognize the worker and gives its membership a role such as report-submitter. That role name is illustrative; the service defines what it permits.

Membership alone does not grant access to every resource. The service checks the exact role against its policy for the requested action. Being an application's owner, or managing an organization, does not automatically satisfy that list policy.

This gives the team a practical control: recognize the worker for report submission while keeping deletion and other teams' records outside its job.

Ask about permission now

A token can optionally carry list role and data claims. Those disclosures are independently configurable and off by default. When included, they describe the state when the token was issued; they do not keep changing inside an existing token.

For incoming machine access, M7's receiving-service ACL check asks about the receiver's list and current role/data. It is separate from ordinary token activity introspection. The receiving app authenticates itself, and SSO checks the active machine token and its signed audience against the receiver's registered resource audiences. The sender's own list claims do not become the receiver's permission decision.

Current ACL checks work even when token role/data disclosure is off. If the team disables the worker’s access or changes its incoming policy to deny it, checking on each protected request avoids relying on an earlier approval. Removing membership does not rewrite an already issued token; a cached decision cannot promise the same immediate effect.

Keep the report boundary

The report service still checks the requested operation, scopes, report ownership and its own business rules. It may accept this team's daily submission and deny a request to delete another team's report, even from the same recognized worker.

Where a token requires proof that the caller possesses a bound key or certificate, the receiving service must verify that proof too. An SSO ACL response cannot do that job for the incoming request. Current M7Roster refuses sender-bound machine tokens because its inbound proof and replay enforcement is not yet connected.

Personal admin owner proxies are bounded as well: the app and its current registered owner must both have active, unexpired membership in the same receiving consumer list. The owner's membership supplies the effective role/data; the proxy does not create or renew either membership, or remove the service's resource checks.

Give automation a clear job

Our worker can spare someone a repetitive upload without acquiring a general pass through the report service. Identity answers who arrived. Current list and role policy help answer whether they are admitted. The service decides what they may do here.

For the receiving checks, start with the incoming machine access guide. For the complementary flow where an app acts for a person, read Let apps work together, with your permission.