Product design question

A Fortune 500 admin wants employees to use Glean agents with GitHub, ServiceNow, and Zendesk, but their security team will only approve launch if they can prevent data leakage, over-permissioning, and unsafe write actions. Design the minimum viable governance controls and the admin/end-user experience you would ship for v1, and explain what you would defer to keep adoption high.

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Tests scoping a minimum viable governance experience for high-risk enterprise agent connectors, balancing security approval against time to adoption.

Name the three risks explicitly: data leakage across permission boundaries, agents having broader access than a user's underlying permissions, and unsafe write actions in GitHub, ServiceNow, or Zendesk.
Design v1 admin controls: permission-aware retrieval that inherits source-system ACLs, a connector-level allowlist of read versus write scopes, and an approval step for any write action.
Design v1 end-user experience: clear indication of which sources an answer drew from, and a visible approval prompt before an agent executes a write action like closing a ticket.
Defer riskier or lower-frequency needs to a later release, for example field-level redaction or custom approval workflows per team, and say so explicitly to the security team.
Get the security team's sign-off criteria upfront, then map v1 scope directly against that checklist so nothing decided later.
Pilot with one connector, likely ServiceNow, before extending the same controls to GitHub and Zendesk.

Anchors v1 on permission inheritance, since data leakage is usually the hardest blocker for security sign-off.
Makes all agent write actions require explicit approval by default, then allows admins to relax that per connector once trusted.
Explicitly defers field-level redaction and per-team custom workflows to v2, naming the tradeoff against launch speed.
Proposes piloting on the single highest-risk connector first to prove the controls before wider rollout.

Trying to ship every governance capability at once instead of a scoped v1 the security team will actually approve.
Designing controls purely for admins and ignoring the end-user trust experience.
Assuming source-system permissions are already clean without a plan for permission drift or misconfiguration.

What would you do if the security team rejects even this scoped v1?
How would you handle a connector whose source system has no granular permission model?