Central control plane
Configure agents, models, connectors, and policy in one place. No per-team workarounds and no ungoverned side channels.
Security & governance
Enterprise AI governance without slowing teams down.
AgenTorQ is the governed control plane for enterprise AI. Every AI Workmate, model call, and data access runs through one policy layer — role-based, PII-masked, guarded, approved, and fully logged. The same governance applies whether you run the standalone Cloud workspace or the Salesforce-native managed package. Not a shadow chatbot — a system of record for how AI is used.
RBAC & profiles
Per-user OAuth
PII masking
FLS & sharing
SOQL / DML guards
Immutable audit
Governance overview
One control plane for how AI is used
Most enterprises adopt AI faster than they can govern it. AgenTorQ inverts that: policy, identity, and observability are enforced centrally — before an AI Workmate ever touches a record, a document, or a model.
Policy enforcement
Define what each role, agent, and workflow may do — then enforce it at runtime on every request, not as an afterthought.
Identity & access
Every action is tied to an authenticated user and their role, mapped to your access model — and, in the Salesforce edition, to your org structure.
Full observability
Prompts, tool calls, model routes, and results are captured for security review, compliance, and cost accounting.
What AgenTorQ governs
- Which models each team, agent, and workflow may call
- Which records, objects, and fields an agent can read or write
- Which connectors and enterprise systems are in scope
- Every prompt, tool call, and response, retained for review
- Approval gates on actions that change data or systems
- Model keys and credentials, isolated per organization and user
Identity & access
The AI acts as a person — never above them
Every request is bound to an authenticated user and their role. Connector access uses per-user OAuth, so an AI Workmate reaches only the systems that specific person is entitled to — with their own tokens, never a shared service account.
Authenticated identity
Actions are tied to a signed-in user and session. The agent inherits that person's entitlements — it cannot act beyond the human behind it.
Per-user OAuth isolation
Each user connects apps under their own OAuth grant. Tokens live in an external credential vault with automatic refresh — scoped per user, never shared or logged.
External credential vault
Model keys and connector credentials are held in an encrypted vault, isolated per organization — kept out of prompts, logs, and client storage.
Identity guarantees the platform enforces
- Per-user OAuth — one person's access never leaks to another
- Automatic token refresh, so access stays current without re-sharing secrets
- Personal chats, memory, and history isolated per user
- Credentials preserved on reconnect — never re-keyed to the wrong identity
- Shared org assets (Workmates, knowledge, keys) separated from private tokens
- Every call attributed to the acting user in the audit trail
Role-based access
Profile-style RBAC, enforced at runtime
Access is defined by role and organization, not by whoever configured an agent. Admins build SFDC-style profiles from a feature-toggle grid, assign them with per-user overrides, and everything is deny-by-default and server-enforced. In the Salesforce edition, roles map to your Salesforce profiles.
Administrators
Own the control plane — configure policy, manage keys, and set organization-wide guardrails.
- Build profiles from a feature-toggle grid
- Manage model & connector policy
- Access audit & usage logs
Builders
Design and ship Workmates within the boundaries administrators set — never outside them.
- Build agents, prompts & workflows
- Use only permitted models & data
- Publish to scoped audiences
Operators & viewers
Run approved Workmates against records they are already entitled to see — nothing more.
- Run governed agents in context
- Inherit their existing record access
- Request actions behind approvals
Boundaries the platform enforces
- Deny-by-default — access is granted, never assumed
- Feature access toggled per role, with per-user overrides
- Record- and field-level scope on every data call
- Model and connector allowlists per role and workflow
- Server-enforced — the client can request, only the server decides
- Org-shared Workmates, knowledge, and keys, isolated per tenant
Data-layer guardrails
Nothing reaches a model until it clears the guards
Between a request and a model sits an enforced pipeline: named PII is masked, reads pass a SOQL guard, writes pass a DML guard, and — in the Salesforce-native edition — field-level security and sharing are enforced in USER_MODE. Only masked, in-scope context ever leaves your boundary.
Governance boundary
Every request is checked against role, model, and data policy before anything runs.
PII masking
SOQL guard · reads
FLS & sharing · USER_MODE
DML guard · writes
Only masked, in-scope context reaches your chosen model
Personal data is redacted, entitlements are honored, and reads and writes are guarded — per provider and per route.
Named PII masked
Sharing & FLS enforced
Guarded reads & writes
- Named PII masked before any prompt leaves — only the masked prompt reaches the model
- Personal-data masking applied to RAG context, not just chat
- Every read passes a SOQL guard; every write passes a DML guard
- Salesforce edition runs in USER_MODE — CRUD, FLS and sharing always enforced
- Object-level include/exclude controls what the AI may ground on
- Cloud edition enforces the same intent via per-connector scopes and masking
Salesforce · OpportunityAcme Corp — Renewal · $240K
Proposed action — approval required
Update Stage to Negotiation and set Next step to “Send redlined MSA.” This action writes to Salesforce and is held until a human approves it.
Approve
Reject
View details
Action approvals
Nothing changes your systems without a human in the loop
Reading is one thing; writing is another. Any action that changes data or triggers a downstream system is proposed as a clear, plain-language action card and held behind an explicit approval — with a preview of exactly what will happen.
- Preview-then-apply on every write and deploy
- Plain-English summary of the exact change proposed
- Approver identity and decision recorded to the audit trail
- Enforced operating modes — Plan never deploys; deletes always confirm
- Configurable per action type, object, and workflow
- Reject or edit before anything reaches your systems
Audit logs
Prove what the AI saw, said, and did
If you can’t audit it, you can’t approve it. AgenTorQ records a structured, immutable trail of every interaction — the actor, their role, the model routed to, the data touched, the approval granted, and the result.
- Actor, role, and organization on every event
- Full prompt, tool call, and model response capture
- Which records and fields were read or written
- Approval decisions and who granted them
- Traceable IDs for security review and cost accounting
- Exportable via API for your SIEM and compliance tooling
// immutable audit event — one per action
{
"event": "agent.action.executed",
"timestamp": "2026-07-07T14:52:09Z",
"actor": "jordan.lee@acme.com",
"role": "Sales Operations",
"org": "acme-emea",
"agent": "Opportunity Risk Workmate",
"model": "claude · policy:sales-tier",
"action": "salesforce.update",
"object": "Opportunity/0065f00000AbC19",
"fields": ["StageName", "NextStep"],
"pii_masked": "true",
"approval": "granted · manager",
"result": "success",
"trace_id": "aq_2f63f0a91c"
}
Model access policies
Any model — under one policy, on your keys
Multi-model is a security decision, not only a cost one. Route each workflow to an approved model with allowlists, fallback, and data-handling rules enforced centrally — and keep every provider key under your own control with BYOK. No team is silently locked to one vendor or one risk profile.
OpenAI
GPT model family, routed under policy with per-role allowlists.
Anthropic
Claude model family for reasoning-heavy, governed workflows.
Gemini model family, selectable per workflow and cost target.
Bring your own
14+ providers plus any OpenAI-compatible or self-hosted endpoint, on your keys.
Model & BYOK policy controls
- Per-role and per-workflow model allowlists
- Bring-your-own-key — credentials stay under your control
- Automatic fallback and routing with latency and cost limits
- No lock-in: swap models without rebuilding Workmates
- Data-handling rules applied per provider and per route
- Every model call logged to the audit trail
See the full multi-model lineup — 14+ providers and hundreds of models — on the Platform page.
Data isolation
Your data stays inside your boundary
Enterprise data never becomes training data by default, and it never crosses tenants. AgenTorQ isolates every layer — identity, storage, credentials, and connector runtime — so context reaches the model only when policy allows.
Governance & policy boundary
Every request is checked against role, model, and data policy before anything runs.
Per-user identity & session
Tenant-isolated storage
Isolated key & credential vault
Governed connector runtime
Scoped model access
Only policy-approved context is passed to an approved model, with data-handling rules per route.
No cross-tenant access
No default training use
Least-privilege context
- Server-side is the source of truth; local storage is only a cache
- Per-user isolation on stored context, memory, and history
- Encryption in transit across every connector and model call
- Credentials isolated per organization, never shared or logged
- Only policy-approved, masked fields leave your systems for a model
- Deployment and data-handling options to match your requirements
Enterprise deployment
Deploy to match your security posture
AgenTorQ meets your environment where it is — from a managed multi-tenant service to a network-isolated deployment, with your own keys and connector runtime under your control. Both deployment editions share the same governed engine.
Managed cloud
A fully managed, multi-tenant service with strict per-organization isolation and rapid onboarding — the standalone AgenTorQ Cloud workspace.
Private / VPC deployment
A dedicated, network-isolated deployment for regulated environments and stricter data-handling requirements.
Salesforce-native install
Install on-platform as an AppExchange managed package — data stays in Salesforce, admin-managed, enforced in USER_MODE.
Enterprise readiness
- Salesforce-native install via AppExchange managed package
- Identity and roles mapped to your Salesforce access model
- Bring-your-own-key across every supported model provider
- Self-hosted connector runtime for sensitive integrations
- API-first — wire audit and controls into your own tooling
- Data-handling options to support your compliance program
Compliance-ready architecture — AgenTorQ does not claim SOC 2, ISO 27001, HIPAA or GDPR certification; it is engineered to support your program. Read our Privacy Policy.
One platform, one governance
The same controls cover everything AgenTorQ does
Governance isn’t a bolt-on. RBAC, masking, guards, approvals, and the audit trail apply across every capability — from AI Workmates to the developer IDE to 600+ connectors.
AI Workmates
Role-aware agents that read data, reason over knowledge, and take approved actions — each bounded by the same policy layer.
Meet the WorkmatesDevSpace Studio
An AI-native IDE for Apex, LWC, Flow and GitHub — ask, plan, edit, diff, approve, deploy, test and fix, all gated by approvals.
Explore Developers600+ connectors
Salesforce and hundreds of apps via per-user OAuth, plus REST, GraphQL, databases and MCP — every call scoped and logged.
Explore ConnectorsFull capability catalog
RAG with citations, enterprise search, workflow automation, document & OCR intelligence, per-user memory — all governed.
See all Features
Security FAQ
Questions security teams ask first
Straight answers on governance, certification posture, data handling, and controls.
How does AgenTorQ govern enterprise AI?
Every AI Workmate, model call, and data access runs through one control plane. Policy, identity, and observability are enforced centrally before an agent ever touches a record or a model — role-based access, model allowlists, PII masking, guarded reads and writes, human approval gates on actions, and an immutable audit log. It is a governed control plane, not a shadow chatbot.
Is AgenTorQ SOC 2, ISO 27001, HIPAA or GDPR certified?
AgenTorQ does not claim SOC 2, ISO 27001, HIPAA or GDPR certification. It is built with a compliance-ready architecture: zero-trust access controls, PII masking, per-tenant and per-user isolation, encryption in transit, an immutable audit trail, and deployment options — managed cloud, private/VPC, and self-hosted connector runtime — designed to support your own compliance program.
How does role-based access control work?
Access is defined by role and organization, not by whoever configured an agent. Admins build SFDC-style profiles from a feature-toggle grid and assign them with per-user overrides. Access is deny-by-default and server-enforced. In the Salesforce-native edition, permissions map to your Salesforce roles and profiles so the AI never exceeds the human behind it.
Does my data become training data or cross tenants?
No. Enterprise data is not used as training data by default and never crosses tenants. Identity, storage, credentials, and connector runtime are isolated per organization and per user. Only policy-approved, masked context is passed to the model you chose, with data-handling rules applied per provider and per route.
How is Salesforce field-level security and sharing enforced?
In the Salesforce-native edition, AgenTorQ runs in USER_MODE, so CRUD, field-level security, and record sharing are always enforced by the platform — the AI can only read or write what the running user is entitled to. Every read passes a SOQL guard and every write a DML guard before it touches your data.
What is captured in the audit log?
A structured, immutable trail of every interaction: the actor and role, the organization, the model routed to, the action taken, the records and fields read or written, the approval that was granted and who granted it, the result, and a traceable ID. It is exportable via API for your SIEM and compliance tooling.
Can I control which AI models each team can use?
Yes. Model access is a policy decision. Set per-role and per-workflow allowlists across 14+ providers, apply data-handling rules per provider and route, and use bring-your-own-key so credentials stay under your control. You can swap models without rebuilding Workmates, and every model call is logged to the audit trail.
Can AI take actions without a human approving them?
Any action that changes data or triggers a downstream system is proposed as a plain-language action card and held behind an explicit approval, with a preview of exactly what will happen. The approver’s identity and decision are recorded to the audit trail, and destructive steps such as deletes always require confirmation.
What deployment options are available for security teams?
Managed multi-tenant cloud with strict per-organization isolation; a private/VPC deployment for regulated environments; and bring-your-own model keys with a self-hosted connector runtime so credentials and traffic stay under your control. The Salesforce-native edition installs on-platform as an AppExchange managed package.
Bring your security team to the table
Walk through the control plane, audit model, and deployment options with our team — or open the workspace and see governed AI in action.
Talk to security — reachout@agentorq.com