ms-tau-sdk 2.0.17.dev66__tar.gz → 2.0.18.dev68__tar.gz

{ms_tau_sdk-2.0.17.dev66 → ms_tau_sdk-2.0.18.dev68}/CHANGELOG.md

@@ -1,6 +1,75 @@
 # Changelog
 
-## Unreleased
+## 2.0.18 — 2026-10-18
+
+- **The Security and access guide and the Tau security skill describe Agent policies.** The
+  platform now decides Agents, and the releases they run on, by the policies on them. The
+  [guide](docs/reference/security-model.md#agent-policies) said that sharing an Agent lets another
+  person use it, that everyone who can view an Agent reads all its Tasks, that an Agent editor stops
+  conversations and cancels Tasks, and that calling another application needs view of it. It now
+  says that `user` talks to the Agent and gives it Tasks, seeing only the Tasks they asked for,
+  `viewer` also sees every Task, `operator` also stops other people's work, `editor` also
+  configures it, moves it to a new runtime build, deletes it and manages its workload, and `owner`
+  also decides who has access; that no policy opens another person's conversation; that whoever
+  creates an Agent holds `owner`, Organization admins hold every action, and owners give policies
+  through `/api/v1/agents/<uid>/access/`; that the Agent's release follows the Agent and takes no
+  policy of its own; that a workload sends an Agent work with its own policy, declared under
+  `access.agents`, and a delegation reaches only Agents the person holds a policy on; and that
+  `call_release()` needs a policy on the application's release that includes
+  `resource-releases.invoke`. `tau_security_and_access` gains an Agents section, the public API
+  reference links `call_release()` to that rule, and troubleshooting and the quickstart no longer
+  speak of sharing an Agent. Existing shares are kept. No SDK code changes.
+- **The Security and access guide and the provider guide show workflow API `3.0.0`.** The
+  platform's workflow API `3.0.0` replaces `2.3.0`: an `access` entry names the policy its workload
+  gets (`policy:`) instead of `level: view` or `level: edit`, and a workflow file of any other
+  version is refused before anything of it is applied, so a project switches its
+  `.mainsequence/workflows` files to `3.0.0` before its next push. The
+  [Security and access guide](docs/reference/security-model.md#secrets) and
+  [Named providers and sharing](docs/guides/project-configuration.md#named-providers-and-sharing)
+  said that `access.secrets` and `access.model_providers` give a policy for a level. They now say
+  that the entry names the policy, such as `policy: value_reader` for a Secret's current value or
+  `policy: user` for a provider, and requester access is declared in a `3.0.0` file. No SDK code
+  changes.
+- **The provider guide, the Security and access guide and the Tau security skill describe
+  model-provider policies.** The platform now decides model-provider credentials and custom
+  endpoints by the policies on them.
+  [Named providers and sharing](docs/guides/project-configuration.md#named-providers-and-sharing)
+  said that people share a configured provider and that Organization admins need no share. It now
+  says that on a credential `user` selects and receives it, including in local Tau, `editor` also
+  refreshes, reconnects and revokes it and sees who has access, and `owner` also decides who has
+  access; that on a custom endpoint `user` sends requests through it and `editor` also changes and
+  deletes it; that the credential's person and an endpoint's creator hold `owner`; that a session
+  counts its owner's policies, never the Agent's workload's; that owners give policies in Command
+  Center or through the record's `access/` routes, and `access.model_providers` gives a workload
+  `user` for `level: view` and `editor` for `level: edit`; and that a refused change answers `403`
+  `missing_action`. The disclosure now goes with giving `user`: the holder can copy the credential,
+  and removing the policy does not recall copies. The
+  [Security and access guide](docs/reference/security-model.md#model-providers) and
+  `tau_security_and_access` gain a Model providers section, and the settings and troubleshooting
+  pages no longer speak of shares. Selection rules and existing shares are kept. No SDK code
+  changes.
+- **The Security and access guide and the Tau security skill describe Secret policies.** The
+  platform now decides Secrets by the policies on them. The
+  [guide](docs/reference/security-model.md#secrets) and `tau_security_and_access` said that a
+  Secret value follows view access, that its creator cannot be removed, and that `can-view/` and
+  `can-edit/` list who has access. They now say that `reader` sees a Secret without its value,
+  `value_reader` reads the current value, `editor` also reads earlier values, sets a new value,
+  deletes it and sees who has access, and `owner` also decides who has access; that the creator
+  becomes its owner and no policy is protected; that `access.secrets` gives a workload
+  `value_reader` for `level: view` and `editor` for `level: edit`; and that
+  `GET /api/v1/secrets/<uid>/access/` and `access/me/` replace `can-view/` and `can-edit/`.
+  Existing shares are kept. No SDK code changes.
+- **The Tau security skill describes team policies.** The platform now decides who can see and
+  manage a team by the policies on it. `tau_security_and_access` said that Organization admins are
+  protected writer members of every team and the only people who manage membership. It now says
+  that any person creates a team and becomes its owner and first member, that the `viewer`,
+  `membership_manager`, `editor` and `owner` policies decide who can see and manage it, and that
+  Organization admins manage every team from their role, with no membership protected. Membership
+  still decides who receives what is shared with a team and what `in_teams()` answers, and a team
+  the person only manages is not in that answer. `in_teams()` is unchanged; the
+  [Security and access guide](docs/reference/security-model.md#teams-and-membership) says the same.
+
+## 2.0.17 — 2026-10-15
 
 - **`team_uids` is removed; the verifier refuses caller assertions that list teams
   ([#103](https://github.com/mainsequence-sdk/ms-tau-sdk/issues/103), ADR 0019).** The platform no

{ms_tau_sdk-2.0.17.dev66 → ms_tau_sdk-2.0.18.dev68}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ms-tau-sdk
-Version: 2.0.17.dev66
+Version: 2.0.18.dev68
 Summary: Workspace-bound Tau application primitives for Main Sequence projects
 Project-URL: Changelog, https://github.com/mainsequence-sdk/ms-tau-sdk/blob/development/CHANGELOG.md
 Project-URL: Documentation, https://github.com/mainsequence-sdk/ms-tau-sdk/tree/development/docs

{ms_tau_sdk-2.0.17.dev66 → ms_tau_sdk-2.0.18.dev68}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ms-tau-sdk"
-version = "2.0.17.dev66"
+version = "2.0.18.dev68"
 description = "Workspace-bound Tau application primitives for Main Sequence projects"
 readme = "README.md"
 requires-python = ">=3.13"

{ms_tau_sdk-2.0.17.dev66 → ms_tau_sdk-2.0.18.dev68}/src/ms_tau_sdk/agent_skills/tau_project_customization/SKILL.md

@@ -184,7 +184,7 @@ Rules for tools that act for the requester:
   a URL, and never sets `Authorization` or an `X-MainSequence-*` header.
 - A delegated call uses the person's ordinary permissions, including administrative ones; any other
   call uses the Agent's own. Each operation decides what it needs. Never infer write permission
-  from view access.
+  from read access.
 - Return to the model only business results, such as rows, numbers, and names. Never return the
   response object, its headers, a token, a proof, or a raw error body.
 - Keep nothing for another turn or another person. The delegation ends with the turn, and a task

{ms_tau_sdk-2.0.17.dev66 → ms_tau_sdk-2.0.18.dev68}/src/ms_tau_sdk/agent_skills/tau_security_and_access/SKILL.md

@@ -163,8 +163,9 @@ What makes it safe:
 
 - No tool takes a Secret value or a Secret name from the model. The name is built from
   `current_requester().uid`, so prompt injection cannot point the tool at another Secret.
-- `delegation="required"` reads the Secret as the person. The platform returns it only if the
-  person can view it; the name is a lookup key, not the protection.
+- `delegation="required"` reads the Secret as the person. The platform returns the value only if
+  the person holds `value_reader`, `editor` or `owner` on it; the name is a lookup key, not the
+  protection.
 - The value exists only inside one call. It never goes into the result, `details`, a log, an
   exception message, a file or a cache for the next turn. It travels in a header, never in a URL,
   because URLs reach logs. Errors from the outside call are caught, and the provider's raw body is
@@ -178,19 +179,19 @@ What makes it safe:
 
 A delegated read returns anything the person can view in the Agent's Environment: what they
 created and what others shared with them, directly or through a team. This holds for Secrets and
-other shared resources. Ordinary Teams use explicit membership: the creator is added once and
-can be removed; current Organization admins are protected writer members. Removing the admin
-role keeps membership and writer access but ends protection. Only Organization admins manage
-membership, and managing a workload that created a Team does not grant Team control. A Team's
-members still receive the resources shared with it. The Full directory remains unchanged.
-See the SDK Security and access guide's **Teams and membership** section for platform rollout.
-The platform enforces sharing; which of those objects a tool uses is part of
-the tool's design. For Secrets, the naming convention states that design:
+other shared resources. A team's members receive what is shared with it, and `in_teams()` answers
+membership. Who can see and manage a team is decided separately, by the `viewer`,
+`membership_manager`, `editor` and `owner` policies on it: any person can create a team and
+becomes its owner and first member, members can see the team and leave it, and Organization admins
+manage every team from their role, without being members. No membership is protected. See the SDK
+Security and access guide's **Teams and membership** section. The platform enforces sharing;
+which of those objects a tool uses is part of the tool's design. For Secrets, the naming
+convention states that design:
 
 - **A personal credential:** a name tied to the person, such as `QUOTES_API_KEY__<person uid>`.
   The person decides whether to share it.
-- **A team credential:** a name the team agrees on, shared with the team for view. The tool reads
-  it for any member.
+- **A team credential:** a name the team agrees on, with `value_reader` attached to the team. The
+  tool reads it for any member.
 - **Someone else's Secret shared with the person:** valid whenever the tool is meant to use it.
 
 Whoever can edit a Secret decides its value, so the tool uses whatever value they set. Granting or
@@ -199,13 +200,68 @@ decision people make through sharing, not one the platform makes for them.
 
 How sharing works:
 
-- The creator of a Secret can always view and edit it, and cannot be removed from it. People who
-  can edit a Secret can share it, for view or for edit, with people and teams.
-- Most people can share only within the teams they belong to; Organization admins can share
-  across their Organization.
-- `GET /api/v1/secrets/<uid>/can-view/` and `can-edit/` list the people and teams with access. A
-  tool can use them when its design needs to, for example to refuse a team key where it expects a
-  personal one. That is a choice of the tool, not a platform rule.
+- Policies on a Secret decide access: `reader` sees that it exists and its name, never its value;
+  `value_reader` also reads the current value; `editor` also reads earlier values, sets a new value,
+  deletes it and sees who has access; `owner` also decides who has access. The creator becomes its
+  owner, and Organization admins hold every policy on their Organization's Secrets from their role.
+- Owners attach and detach these policies for people, teams and workloads; whoever manages a
+  workload can also give it a policy they hold, and anyone can remove their own. No policy is
+  protected: an owner can remove the creator's. Nobody gives a policy with more than they hold, and
+  people other than Organization admins give access only to people who share an active team with
+  them, to teams they belong to and to workloads they can view.
+- `GET /api/v1/secrets/<uid>/access/` lists who holds which policy, for editors and owners, and
+  `GET /api/v1/secrets/<uid>/access/me/` answers what the caller may do with it. A tool can use
+  them when its design needs to, for example to refuse a team key where it expects a personal one.
+  That is a choice of the tool, not a platform rule.
+
+## Model providers
+
+The model a session runs on uses a provider credential or custom endpoint that the session owner
+may use; a delegated child session uses its parent's owner. A policy that only the Agent's workload
+holds does not count in a person's session. Policies on the record decide who may use it, held
+directly or through a team:
+
+- `user` uses it: a credential is selected and delivered to sessions and workloads, including local
+  Tau, and a custom endpoint receives their requests.
+- `editor` also refreshes, reconnects or revokes a credential, or changes or deletes an endpoint,
+  and sees who has access; `owner` also decides who has access.
+- The credential's person and the endpoint's creator hold `owner`, and Organization admins hold
+  every action on their Organization's records. Owners give and remove the policies in Command
+  Center's provider settings or through `/api/v1/model-provider-credentials/<uid>/access/` and
+  `/api/v1/custom-model-providers/<uid>/access/`; a refused change answers `403` `missing_action`
+  with the `granting_policies` that would allow it.
+
+Holding `user` delivers the credential, or the endpoint's stored authentication, to the holder's own
+runtime, including local Tau, where it can be copied; removing the policy stops later deliveries,
+not copies already made. To let a team run an Agent on one credential, its owner gives the team
+`user`.
+
+## Agents
+
+Policies on an Agent decide who may talk to it and manage it, held directly or through a team:
+
+- `user` talks to it and gives it Tasks, seeing only the Tasks they asked for; `viewer` also sees
+  every Task of the Agent with its requests and results; `operator` also stops any Task or
+  conversation run, other people's included; `editor` also configures it, moves it to a new runtime
+  build, deletes it, manages what its workload can reach and sees who has access; `owner` also
+  decides who has access.
+- A conversation stays its owner's: no Agent policy, `owner` included, reads another person's
+  conversation (Organization admins can read it, never change it), and only a Task's requesters
+  continue it. On an Agent that acts for its requester, a Task is visible only to its requesters
+  and Organization admins.
+- Whoever creates an Agent holds `owner`, and Organization admins hold every action on their
+  Organization's Agents. Owners give and remove the policies through
+  `/api/v1/agents/<uid>/access/`; a refused change answers `403` `missing_action` with the
+  `granting_policies` that would allow it, and an Agent the caller holds no policy on answers `404`.
+- The release an Agent runs on takes no policy of its own: `viewer` and `operator` on the Agent see
+  it, and `editor` and `owner` change it.
+
+A tool reaches Agents and their Tasks with the caller's policies: the person's in a delegated call,
+the Agent's workload's otherwise. To send another Agent work without a delegation, the workload
+needs its own policy on that Agent, declared under `access.agents` in its workflow file, usually
+`policy: user`. Calling another application with `call_release()` needs a policy on its release
+that includes calling it (`resource-releases.invoke`, which every release policy has), and the
+platform checks it again on every call.
 
 ## Checking the person's teams
 
@@ -220,7 +276,9 @@ if person is None or REPORTS_TEAM_UID not in await person.in_teams([REPORTS_TEAM
 ```
 
 - `await in_teams(team_uids, *, max_age_seconds=None)` returns the subset of `team_uids` the
-  person is an active member of, as a `frozenset`. Unknown and inactive teams are left out.
+  person is an active member of, as a `frozenset`. Unknown and inactive teams are left out, and so
+  is a team the person only manages: managing a team, also as an Organization admin, does not make
+  anyone a member.
 - On the turn's requester it answers only while that person is the verified caller of the request
   the turn runs in, such as a chat or A2A Message they sent. A turn with no such request raises
   `TauSDKError`: a Task attempt the platform dispatches, a turn that resumes a caller delivery, or
@@ -272,4 +330,5 @@ Patch the extension module's `current_requester` and `platform_client` with fake
 - Secret values stay inside one call, in headers, never in results, logs, errors, URLs or caches.
 - The naming convention says whose Secrets the tool uses, and the people sharing them know it.
 - A refused delegated call is reported, never retried as the Agent.
-- The Agent's workload holds no grants it does not need, and none on people's Secrets.
+- The Agent's workload holds no grants it does not need, and none on people's Secrets; `user` is
+  enough on an Agent it only sends work to.