Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-11 · Instrument version 1.0.0
What Matters
A purchased account can support several different uses, each with different contractual conditions. Name the actor, automation route, downstream users and commercial activity before interpreting the terms. DN’s Agent-Use Entitlement Matrix records support, restrictions and uncertainty without producing a legal permission score. API integration, account sharing and resale must remain separate questions.
An employee buys a software seat. Later, a workflow runs unattended, a contractor maintains it and customers receive a service built on its output. The original purchase now sits inside a chain of actors and activities that may differ from the use described at checkout.
The procurement task is to map that chain to the actual agreement. Technical success proves that access worked at a moment in time. It does not establish that the account, licence or service terms cover every delegated action. Nor does a restriction on reselling raw access automatically prohibit every application built with an API.
DN Evidence Block
Sources reviewed: 2026-11-11 · Evidence type: Current public provider agreements, read as concrete examples of distinct permission categories, and an original DN entitlement-record method.
Scope: Service-use rights for a specified organisation and workflow. Negotiated orders, applicable law and product-specific terms may alter the relevant analysis.
- The OpenAI Services Agreement, effective 1 January 2026, permits API integration into customer applications while separately restricting credential sharing, account resale and API-key transfer. Those are distinct clauses and activities.
- Anthropic’s Commercial Terms, effective 17 June 2025, permit powering customer-facing products while separately restricting resale of the service without express approval.
- The AWS Customer Agreement, updated 29 October 2026 when checked, distinguishes account and end-user responsibilities from credential restrictions, including a stated private-key exception for agents and subcontractors working on the customer’s behalf.
Not established by this work: No customer agreement or deployed workflow has been legally reviewed. The tool records user-entered interpretations and evidence references.
Original DN instrument · version 1.0.0
DN Agent-Use Entitlement Matrix
Record the status of six service-use questions for one specified workflow. This instrument preserves your evidence classification; it does not interpret terms or grant permission.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
This record is not legal advice, a licence determination or a compliance score. Public terms may differ from the agreement governing a particular customer. It does not inspect downstream content rights, technical security or actual access.
1. Who is the licensed user or account holder?
Record the contracting entity, the product, the seat or usage model and the identity under which the workflow operates. A named employee, an organisation account and a supported service account are not interchangeable descriptions.
Map the actual actors without assuming that each agent process is a separate licensed person or that one human purchase covers every process. The relevant agreement may define users, accounts or authorised personnel in a particular way. Preserve those definitions with the record.
Documented example: GitHub’s terms distinguish human account creation from a permitted machine account used for automated tasks, with an individual responsible for it. That specific distinction is useful evidence; it is not a universal rule for every vendor.
2. Is unattended or automated operation included?
Describe what the agent does, how frequently it acts and whether a person is present. An agent reading an exported file, controlling a browser session and calling an API use different access routes.
Look for the clauses and product documentation that apply to the chosen route. If they are silent or contradictory about a material activity, record the question for the supplier or an appropriate adviser. Do not convert silence into permission or prohibition through a generic rule.
Keep the scope concrete: one organisation, one workflow, named operations and a stated environment. A broad question such as “Are agents allowed?” gives a supplier too little detail to resolve the use that matters.
Documented example: Microsoft’s Power Automate guidance distinguishes user/capacity licensing and attended, unattended and hosted capabilities. Inspect the applicable agreement and current entitlement table instead of assuming every automation mode comes with one seat.
3. Which API or integration route is authorised?
Record whether the purchase includes API use, which product terms govern it and which entity owns the credentials. An API-enabled product and a human-facing subscription can have different contracts even when they share a brand.
Describe the customer application itself. Who sends requests, who receives results and where are credentials held? An application that uses an API under its own account is a different arrangement from selling another party a login or handing over a raw API key. The public agreement examples above illustrate why these questions should not be collapsed.
4. Who may act on the account holder’s behalf?
A contractor maintaining a workflow, an employee supervising it and a third-party service making calls can each introduce a delegation question. Record the permitted role, access scope and any required confidentiality or security arrangement.
The word “agent” in a contract may refer to a legal or commercial representative rather than an autonomous software process. Read the definition and context. Do not assume that a familiar technical label carries the same meaning in every agreement.
Document how delegated access is revoked or replaced. The entitlement record should identify the responsible organisation and the approved access arrangement, without embedding passwords or secret keys in the matrix.
5. What may downstream customers receive or do?
Identify whether customers receive an answer, a hosted application, a copy of a dataset or direct service access. The commercial and technical design determines which clauses require attention.
Trace one transaction through the full chain. A company may buy access, allow a contractor to operate an integration, provide results to customers and retain records for later use. Each handoff should state the actor, data or capability transferred, purpose and governing evidence. One purchase can support many end users under some arrangements, but that does not make every form of sharing permissible.
6. Does the business involve resale, sublicensing or credential transfer?
Use the supplier’s actual definitions and any express approval. A reseller programme, a customer application and a managed service may have different terms. An invoice for a subscription does not answer which model applies.
Do not infer output copyright rights from service-use permission, or service-use permission from ownership of an output. Those are separate questions. This matrix concerns how the service may be accessed and offered; content rights need their own record.
If the proposed commercial model depends on an unresolved interpretation, make that dependency visible before pricing or promising the service to a customer. A bounded written clarification is more useful than an informal assurance that “commercial use is fine.”
Methodology, limitations and corrections
DN read current public provider agreements to identify distinctions between application integration, account identity, delegation and resale. The article paraphrases a small set of clauses as examples and does not determine a reader’s rights. The six-question method and synthetic matrix are original procurement aids. For a real assessment, retain the full governing agreement, order forms, service-specific terms, version dates, intended-use description and qualified interpretation of material uncertainty. Update the record when the actors or commercial design change.
Use the DN Agent-Use Entitlement Matrix
Create one row for each of the six questions. Record the intended activity, the relevant entity and product, the exact agreement version, the supporting clause and any condition that must remain true. Add an owner and a review trigger.
| Record element | Why it matters |
|---|---|
| Intended activity and actors | Prevents a broad permission from being applied to a different use |
| Governing record and version | Shows which terms were actually considered |
| Clause and interpretation | Makes the conclusion reviewable |
| Conditions and unresolved questions | Preserves limits on the proposed workflow |
| Owner and change trigger | Connects the record to operating responsibility |
The interactive tool records five states: supported, conditional, excluded, unresolved and not applicable. These are the recorder’s classifications. The tool cannot read the agreement, decide the legal meaning of a clause or approve the use.
A synthetic example might record a supported API route and downstream application use, while delegated contractor access remains unresolved and raw credential resale is excluded. The result should preserve each state. Averaging them into a percentage would hide the one condition that can block the proposed design.
Mark an activity inapplicable only when it is outside the actual workflow. If customers are already receiving raw access, the resale question cannot be removed simply because the business describes itself as an application.
Turn the record into a procurement and operating decision
Resolve material uncertainty with a precise description of the use. Include the contracting entity, product, actors, access route, customer experience and any transfer of credentials or copies. Ask which agreement or amendment supports the answer and retain the response through the normal contracting process.
Translate conditions into controls where possible. A supported internal use may require keeping an external distribution route disabled. A permitted delegation may require a defined operator role. The record should identify the person responsible for keeping those conditions true.
Revisit the matrix when the workflow changes. Adding customers, changing the account owner, moving from a user interface to an API or handing maintenance to a third party can change the relevant questions even if the underlying model remains the same.
Keep procurement conclusions separate from a live technical test. A successful login does not settle the licence; a favourable contractual interpretation does not prove that the workflow is reliable. Both need appropriate evidence before the complete service is promised.
The useful result is a traceable entitlement record for the intended design, with exclusions and unresolved points explicit. It gives purchasing, engineering and the responsible adviser a common object to inspect instead of relying on a vague claim that the software “allows agents.”
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version1.0.0, 2026-11-11. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does one seat automatically authorise an unattended agent?
The applicable terms and product arrangement determine that question. Describe the actual route and actor, then preserve the relevant clause or unresolved point.
Does a restriction on resale prohibit every API-powered product?
That conclusion cannot be drawn generically. Application integration and raw service or credential resale can be addressed separately in the governing agreement.
Can the matrix establish that a use is permitted?
No. It records the interpretation and evidence entered by the user. Material contractual uncertainty needs the appropriate supplier clarification or professional review.
Primary sources
- OpenAI Services Agreement. Distinct application integration, account, end-user and API-key provisions; effective 1 January 2026. Reviewed 2026-11-11.
- Anthropic Commercial Terms of Service. Customer-facing use and separate service-resale restriction; effective 17 June 2025. Reviewed 2026-11-11.
- AWS Customer Agreement. Account/end-user responsibilities and credential restrictions with stated delegation exception; updated 29 October 2026. Reviewed 2026-11-11.
- GitHub Terms of Service. Bounded account/machine-account example; applicability depends on the buyer’s governing agreement. Reviewed 2026-11-11.
- Microsoft Learn: Types of Power Automate licenses. User/capacity and attended/unattended/hosted entitlement distinctions; no price claim. Reviewed 2026-11-11.
Turn the finding into a decision
Research Desk: Commission a service-use evidence map for one proposed workflow and its supplier agreements. The deliverable identifies the relevant clauses, actors, conditions and questions for supplier or legal review. DN sells research services; this scope does not provide a legal opinion, negotiate permission or certify the deployment.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
