.png)
Clone.Me: Governance Built for Agentic AI
Security & Governance Whitepaper
Artificial intelligence has crossed a threshold. It no longer just generates text; it acts. Modern AI agents log into systems, update records, send communications, and make decisions inside the workflows that run a business. This shift, from AI as a conversational tool to AI as an operational actor, changes the nature of the risk entirely.
The question enterprises must now answer isn't just "is our AI accurate?" It's: "Can we prove what our AI did, who authorized it, and why?"
At Clone.Me, we believe governance cannot be a policy layered on top of an AI system after the fact. It has to be the architecture the AI runs on. This whitepaper describes how Clone.Me's Clone Studio platform enforces security and governance at the object level, not the prompt level, so that every action an AI agent ("Clone") takes is authenticated, authorized, and auditable by design.
Who this document is for: security and compliance teams evaluating Clone.Me, IT and procurement stakeholders conducting vendor risk assessments, auditors and regulators seeking to understand our control environment, and partners building on our platform.
What differentiates Clone.Me:
The Governance Challenge in Agentic AI
Traditional AI security models were built for a world where the primary risk was a bad output, a hallucinated answer, an inappropriate response, a leaked snippet of training data. Governance in that world meant content filtering and prompt-level instructions.
Agentic AI breaks that model. When an AI agent can create a record, send an email, modify a permission, or execute a transaction, the risk moves from what the model says to what the agent does. Guardrails that live only inside a prompt, "please don't do X" — are fragile by design. Prompts can be misread, deprioritized under competing instructions, or simply forgotten across a long-running conversation. A rule that only exists as a suggestion to the model is not a control. It's a hope.
This creates a governance gap that most AI platforms have not fully addressed:
Clone.Me was built around a simple governing principle: rules that matter should be enforced by the system, not requested of the model. The sections that follow describe how that principle is implemented in practice, from infrastructure through to the governance layer itself.
This approach is also built with an eye toward the direction of AI regulation broadly, including risk-based frameworks like the NIST AI Risk Management Framework and emerging AI-specific regulatory regimes such as the EU AI Act, which increasingly expect organizations to demonstrate accountability, oversight, and traceability for automated decision-making, not merely intent.
Architecture Overview
Security begins below the application layer, in how the platform itself is built and deployed.
Multi-cloud deployment. Clone Studio runs primarily on Google Cloud Platform (GCP), with failover and secondary deployment on Microsoft Azure. This multi-cloud design provides resilience against regional outages and allows enterprise customers to align with preferred cloud providers or data residency requirements. Both GCP and Azure bring their own world-class physical security and independent certifications (including ISO 27001 and SOC 2) that underpin our infrastructure.
Microservices and containerization. The platform's backend is composed of containerized microservices, orchestrated in secure clusters and grouped by function into dedicated Virtual Private Cloud (VPC) networks. This isolates services from one another, limits blast radius in the event of a compromise, and allows consistent security enforcement across both cloud environments.
Zero-trust principles. Internal services authenticate to one another via secure channels and service identities. All internal API and RPC calls are encrypted and require valid credentials or certificates — meaning that even if a network boundary were breached, lateral movement between services is not possible without proper authentication. Nothing inside the network is trusted by default.
A model-agnostic execution layer. Rather than building the platform around a single AI provider, Clone.Me's architecture sits above the model layer. Today that includes OpenAI, Anthropic, Google, and open-weight models. When a new model is released, or an existing model improves, skills built on Clone.Me's architecture can take advantage of that improvement without requiring the customer's governance posture to be rebuilt. This is a deliberate hedge against model-specific risk and vendor lock-in; governance is a property of the platform, not of whichever model happens to be underneath it at a given time.
Identity & Access Management
Access control is the first line of defense in any system that can take action on an organization's behalf.
Authentication. Every route in Clone Studio requires a logged-in, authenticated user unless explicitly allowlisted, and every such exception is documented with a stated reason. This is a default-deny, fail-closed model: access is denied unless specifically granted, rather than granted unless specifically denied. The platform supports Clone.Me-managed authentication as well as sign-in through Microsoft and Google, with scoped API tokens available for approved integration scenarios.
Role-Based Access Control (RBAC). Organization administrators define roles — such as Admin, Knowledge Manager, and User — and assign permissions that determine who can view or edit content, configure integrations, or manage other users.
Object-level permissioning. Beyond role assignment, Clone Studio enforces access at a granular, object level, spanning organizations, child organizations, departments, individual Clones, skills, and individual users. This authorization model allows customers to enforce precise, least-privilege access aligned with their own internal structure and regulatory requirements, rather than relying on a single flat permission tier.
Internal access controls. Clone.Me holds its own engineering team to the same standard we ask of our customers. Internal access to production systems is just-in-time, enforced with multi-factor authentication and single sign-on, and fully logged. There is no standing engineer access to sensitive systems; access is granted only when needed, for as long as it's needed, with a documented record of who accessed what and why.
Data Protection
Encryption in transit and at rest. All customer interactions with Clone Studio occur over TLS 1.2+ encrypted connections. Data at rest is encrypted using AES-256, with AES-GCM specifically applied to credential and token storage, our highest-sensitivity data category.
Multi-tenant logical isolation. Each customer organization's knowledge bases, embeddings, metadata, and skills data are logically isolated to prevent any cross-tenant access. This isolation is enforced at the application and data layer, not assumed as an incidental byproduct of infrastructure.
Credential handling. Plaintext tokens never touch the database. Tokens are decrypted only at the precise moment a skill needs them to execute an authorized action, and are never exposed in chat interfaces, list views, or detail views — even to authorized users within the customer organization.
Knowledge base protection. When a request involves enterprise knowledge, it is routed through Clone Studio's knowledge services, which support connections to enterprise-grade vector databases. Customer knowledge assets, documents, FAQs, embeddings, and associated metadata, are logically isolated by tenant, encrypted in transit and at rest, and access-governed so that users and Clones only retrieve content they are authorized to see.
Customer control. Enterprise customers have options for customer-managed encryption configurations, and retain visibility into how integrations are enabled, how retention is configured, and how access policies are applied across their organization. Clone.Me acts as a steward of customer data, not its owner.
The Governance Layer: Enforcement, Not Instruction
This is the core of what differentiates Clone.Me's approach to agentic AI governance.
Object-level policy enforcement. Most AI platforms attempt to constrain agent behavior through natural-language instructions embedded in a prompt — asking a model to remember and follow a set of rules. Clone.Me does not rely on this approach for governance-critical policies. Instead, MUST and MUST NOT policies are enforced at the object level, within the system itself, evaluated and applied by the platform before an action is permitted to execute, independent of what any individual model "decides" to do with a natural-language instruction.
Default-private visibility. Every Clone's visibility defaults to private. Sharing is never the default state; it is a deliberate, explicit action taken by an authorized user. This inverts the common pattern where new AI tools default to broad visibility and require someone to notice and lock them down after the fact.
Consistent enforcement across every organization. Role-based access governing who can create, edit, or deploy a Clone is enforced the same way across every customer organization on the platform, not customized or weakened on a case-by-case basis.
Complete, organization-reviewable audit trails. Every action a Clone takes writes to a full audit trail. Critically, this trail is reviewable by the customer organization itself — not solely accessible to Clone.Me internally. Accountability is not something customers have to request, or trust exists; it's something they can see.
Together, these controls mean that governance in Clone.Me is not a promise layered on top of the platform. It is a structural property of how the platform is built.
Agent Identity & Delegated Identity
As agentic AI systems move from answering questions to taking action, updating records, retrieving internal data, invoking connected tools, and contacting customers — a new governance question emerges that most platforms have not architected for: not simply whether an AI system can complete an action, but whether an organization can determine which agent acted, under whose authority, and with what scope of permission.
Clone.Me treats this as two related but distinct architectural requirements: agent identity and delegated identity.
Agent Identity
Agent identity is the principle that an AI agent must be a distinct, verifiable actor within enterprise systems, not an invisible extension of whoever deployed it, and not a shared credential borrowed from a human session. Consistent with zero-trust workload identity models, every Clone.Me Clone is issued:
This matters because, without a distinct agent identity, organizations cannot isolate what a given agent touched, cannot investigate anomalies attributable to a specific workflow, and cannot build reliable accountability into automated decision-making.
Delegated Identity
Identity alone is not sufficient. A Clone.Me Clone does not hold standing authority of its own. Instead, it acts on behalf of a human principal or system, under a grant of authority that is scoped, time-bound, and revocable. In practice, delegated identity is expressed through several mechanisms:
Together, agent identity and delegated identity answer two questions simultaneously that traditional application security models were not designed to separate: who is this actor, and under whose authority, with what scope, is it acting.
Why This Matters
As agentic AI matures, the material risk to an organization is not which underlying model it selects; it is whether governance, identity, and delegated authority travel with the agent itself, consistently, across every system it touches. A policy that exists only as a system prompt instruction can be forgotten, bypassed, or reinterpreted. A policy enforced at the object level, tied to a verifiable agent identity and a scoped delegation grant, cannot.
Clone.Me is built on this principle: default-deny, fail-closed access; encrypted, scoped credentials; object-level policy enforcement; and complete, organization-reviewable audit trails for every action a Clone takes.
Pre-Deployment Assurance: CUAT
Governance does not end once a skill is designed, it begins before that skill ever reaches a customer environment.
Before any new skill built through Clone.Me's Skillforge development process ships to production, it undergoes Clone User Acceptance Testing (CUAT), an automated validation process that runs approximately 150 simulated prompts against the skill to evaluate its behavior across a range of expected and adversarial inputs.
This reflects a broader principle in how we think about agentic AI risk: testing before deployment matters as much as auditing after deployment. Audit trails tell you what happened.
Pre-deployment testing is designed to reduce how often something goes wrong in the first place. Both are necessary; neither is sufficient on its own.
Third-Party AI Model Governance
Clone.Me integrates with best-in-class large language models, including OpenAI's GPT models and Anthropic's Claude, alongside Google and open-weight models, via API.
Data handling with model providers. Customer data sent to these underlying AI models is not used to train them by default, and is retained only briefly (up to 30 days) for abuse-monitoring purposes by the providers, consistent with their published privacy practices. Both providers apply strong encryption and maintain their own compliance postures, including SOC 2 Type II attestation, with additional certifications such as ISO 27001 held by certain providers, and Business Associate Agreements (BAAs) available for HIPAA-regulated use cases.
- new models, new providers, new regulatory expectations on model providers themselves- Clone.Me's governance posture is designed to remain consistent
Ongoing vendor oversight. Clone.Me maintains enterprise agreements with model providers, continuously reviews their policies and technical controls, and monitors updates to their privacy practices to remain aligned with emerging requirements.
Why this matters strategically. Because Clone.Me's governance and security architecture sits above the model layer rather than being embedded within a single provider's ecosystem, customers are not exposed to a single point of model-vendor risk. As the underlying AI landscape shifts, new models, new providers, new regulatory expectations on model providers themselves, Clone.Me's governance posture is designed to remain consistent, because it doesn't depend on any one model's internal behavior.
Compliance Program & Roadmap
Clone.Me maintains an active internal Governance, Risk, and Compliance (GRC) program, supported by external compliance partners: Cognisys, which supports broader compliance readiness and program development, and Vanta, which provides continuous control monitoring, policy management, evidence collection, and vendor oversight.
We believe transparency about compliance status is itself a governance obligation. Below is our current, honest posture:
GDPR — In place today. Alignment in place; Data Processing Agreements (DPAs) available to clients.
HIPAA — Available today. Business Associate Agreements (BAAs) offered to clients ahead of formal certification.
SOC 2 Type II — In progress, targeted Q4 2026. Control environment, access management, audit logging, incident response, and monitoring processes actively maturing toward independent audit and attestation.
ISO 27001 — Roadmap: Information Security Management System (ISMS) certification.
ISO 42001 — Roadmap: AI Management System certification.
EU AI Act — Roadmap: Monitoring and preparing; aligning internal AI governance controls (documented risk management, human oversight, transparency, audit logging) with obligations as they phase in, building on the ISO 42001 program.
Ongoing alignment work as the regulatory framework and its technical standards mature
We name items as roadmap deliberately, rather than implying certification before it is earned.
Once SOC 2 Type II attestation and other certifications are complete, reports and relevant documentation will be made available through customer trust channels.
Customer Control & Transparency
Governance is a shared responsibility, and Clone.Me is designed to give customer organizations real visibility and control rather than requiring blind trust.
Full audit visibility. Customer administrators can review the complete audit trail of Clone actions within their own organization, not a summarized or redacted version, but the same record Clone.Me itself would use to investigate an issue.
Configuration control. Organizations retain control over how integrations are enabled, how data retention is configured, and how access policies are applied across their org, child orgs, departments, Clones, and individual users.
Data ownership and portability. Every Clone accumulates organizational knowledge and memory over time as it operates within a business — and that memory belongs to the organization, not to Clone.Me. It is exportable, not held hostage inside the platform.
"We process, we don't migrate." For supported integrations, including Salesforce, HubSpot, Meta, Google, Microsoft, Yardi, and a growing library of connectors — Clone.Me is designed to operate on data at its source rather than requiring customers to migrate their systems of record into our platform. This reduces duplication risk and keeps the customer's existing data governance model intact.
Conclusion: Governance as a Competitive Advantage
As AI shifts from a conversational tool to an operational actor inside real business systems, governance stops being a compliance checkbox and becomes core infrastructure. Organizations adopting agentic AI need confidence not just that their AI works, but that its actions are authorized, its behavior is tested before it ships, its record is auditable, its agents carry verifiable identity and scoped delegated authority, and its compliance posture is honestly represented.
That is the architecture Clone.Me is built on: governed at every layer, not governed on top.
We welcome security questionnaires, due diligence requests, and direct conversations with customers, partners, and auditors evaluating our platform. As our compliance program matures — including SOC 2 Type II attestation and ISO certifications- updated documentation will be made available through our customer trust channels.
Appendices
Appendix A — Glossary
Appendix B — Compliance Milestone Timeline
Appendix C — Shared Responsibility Summary
Appendix D — Contact For security questionnaires, SOC 2 report requests (upon completion), or DPA/BAA requests, contact: Scott Bogdan — sbogdan@clone.me
