TASIP-008: Org-level policy templates

[ryw]

Status: Draft — open for input · Category: Enhancement

Summary

Define governance policy once at the org level (e.g. "high-audit" vs "light-touch") and have workspaces inherit it — tightening but not loosening. Enterprises get consistent guardrails across many teams without micromanaging each workspace.

Why

At one team, per-workspace settings are fine. Across dozens of teams, you need a way to set a floor centrally and let teams go stricter, not looser — and to see when someone overrides it.

Sketch

• Org admins define named policy templates.
• Workspaces inherit; they can tighten but not loosen.
• Template version diffs and override events (with justification) land in the audit log.
  (Provisional — the shape changes based on the discussion.)

Open questions

• What's in a policy template (review rules, retention, connection allowlists)?
• How do template updates roll out to inheriting workspaces?
• What overrides require justification vs are simply blocked?

How to help

React 👍 if you want this, and comment with your use case, constraints, or pushback. This is a draft Tembo Agent Studio Improvement Proposal (TASIP); your input shapes it before it becomes scheduled work.

[kevine824-alt]

@ryw would like to dig into the security pieces and governance as this issue continues to be a focal point. Some ideas below have tickets and I will plan to create tickets for other ideas below. I think a security section in settings should be available with allowing the user to have more autonomy and control over what is shared and how it is shared to those on the instance.

Overall thought: loose on building, tight on data. Usability matters, so building and changing agents should start close to how it works today with tighter options available. What agents read is different, so visibility of runs and sensitive agents should be tight by default. A "light-touch" and a "high-audit" template would cover most customers.

The controls I'd want in a template, roughly in order of how often they came up:

1. Change review - default: changes go live right away (YOLO), which is needed or nothing gets done. Tighter option: tie it to certification. New builders start as a junior operator where anything that expands reach (new connections, new tools, send/write tools, run-as, schedule) needs a manager or admin to approve, and certified operators only need approval for new agents going live. A review queue after the fact lets a manager see what changed and roll back without slowing anyone down. Needs a role between viewer and operator.
2. Run-as - default: as today, with the Team dashboard showing each member's connections and automations. Small additions: a one-time notice when someone is set as the run-as for an automation, and a hover on 30-day runs showing which agents ran and who started them. No per-run alerts. Manual runs as others stay open for testing.
3. Run and agent visibility - tight by default. Normal users see only runs made in their own name. Managers see their team's, admins see all. Sensitive agents are gated by their connections: if an agent declares a connection you don't have (QuickBooks for example), you can see it exists in search but can't open its definition or runs. Require every connection the agent declares, not just one, and keep names/descriptions generic. Other definitions stay read-only so people can learn from each other's agents. Needs a team/manager concept. Agents that read other agents' runs see what their run-as person can see, so fleet-wide checks run as an admin and should say when their view is partial. Retention settings belong here too.
4. Tool allowlists - ties to run-as, since together they decide what an agent can do in someone's name. Tighter option: when an agent runs as another member it's limited to read and draft tools, and send/write tools only run as yourself or with approval. Draft-only tools have been the strongest guardrail we have at Carefeed.
5. Cost - a per-run limit that flags or blocks. Carefeed's governance draft uses $3 a run as the trigger for a second look.
6. Memory - option to keep memory to one instance when sensitive data is involved.
7. Alerts - failed runs and platform-wide issues, on by default. The Oct 1 credit outage was found by discovery, not an alert.

On the open questions:

• Overrides - loosening below the org template is blocked, tightening needs no justification.
• Rollout - template updates apply to inheriting workspaces with a notice to workspace admins, not silently.
• Audit log - override events plus who ran an agent as whom would cover most of what a security review asks for.