Administration & security

The intended experience is to provision a Clone as naturally as a company account and assign it to one person. The company owns access, permissions and permitted autonomy. Administration belongs in the web dashboard, covering people, Clones, integrations, activity and spending.

Clone is intended to use dedicated accounts, starting with its own Google identity, inbox and calendar. It should be invited to services and use its own identity subject to policy, rather than generally impersonating the person’s personal accounts.

The product direction includes authorized access to the Clone’s Google credentials and account takeover by its person. Human credential access needs its own authentication, audit, recovery and revocation flow; it is separate from the agent’s access.

Security must be enforced outside model prompts. The first-build design checks identity, action, destination, current policy and inherited information restrictions at execution time. Browser, network and shell access must not bypass that boundary.

Separate screens are not sufficient isolation for sensitive data. The initial demo uses synthetic accounts, fake secrets and synthetic information labels. Handling real sensitive workloads requires boundary tests; the design is not evidence of production readiness.

The agent should see a reference to a secret while the application stores its value and resolves it only for an approved destination and operation. A reference must not resolve into an arbitrary message, URL or command.

{{email}}
{{google_password}}

The security requirements exclude secrets from model output, captures and logs. Remaining exposure paths must be identified and tested; placeholder substitution alone is not protection.

Account recovery, MFA, reassignment and employee offboarding need explicit handling. The customer procedures are not decided yet. Do not assume that reassignment transfers every conversation or that offboarding automatically resolves every account and session.

• Define who can recover or take over the Clone’s accounts.
• Define how access and credentials are revoked when a person leaves.
• Decide reassignment, retention and information access rules.