Least-privilege by default
The co-worker only ever holds the data scopes the workflow needs. We don't ask for "broad access" and narrow later. We ask for the minimum and expand only with explicit approval.
Enterprise · Security brief
Built so your security team becomes an ally, not a blocker.
The questions your CISO will ask – and the answers we already have.
§01 · Where does the data go?
Often: nowhere new.
For sensitive workflows we recommend Model C – customer-hosted. The co-worker runs in your environment. Your data does not need to move to Riyalabs.
Model C · Customer-hosted
Recommended for sensitive data
Your cloud
Owner
Agent runtime
Credentials
Customer data
Audit logs
Prompts & outputs
Everything that touches sensitive data stays in your environment, behind your firewall, under your identity provider, with your retention policy.
Riyalabs
Implementation partner
No data residency
No customer data
No credentials stored
Riyalabs is your implementation and operations partner. We help configure, ship, and review – we don't host your data.
Your data does not need to move to Riyalabs. We map the workflow, identify the minimum context, and choose the deployment model that fits your risk level.
§02 · Who can see what?
Least-privilege, role-based, per-source.
Access is composed of three layers – and we design every co-worker against all three from day one.
Role-based controls
RBAC roles for viewer, reviewer, approver, and admin are explicit and owned by a named human on your side. SSO and your identity provider drive the membership – not us.
Per-source scoping
One token per source, scoped to the minimum required. Read-only by default. Write actions are a separate scope and always run through an approval gate before they fire.
§03 · How do we revoke?
Kill switch, rollback, audit log.
If a co-worker behaves badly, you should not need to call us first. Owner-controlled, in your environment, documented before launch.
Kill switch
A single owner-controlled toggle stops the co-worker immediately. No support ticket. No waiting. The co-worker stops reading, stops drafting, stops sending.
Versioned rollback
Prompts, tools, and data scopes are versioned. Roll back to any previous version with one action. Any earlier outputs are still traceable to the exact version that produced them.
Audit log
Every action, every prompt, every approval, every send – recorded with the user, the timestamp, and the scope used. The log is yours, in your environment.
Disable flow
From "stop now" to cold, in four steps.
1
Toggle offOwner clicks Disable. The co-worker stops accepting new work immediately.
2
Drain queueIn-flight items are held. None auto-send. Owner reviews and decides.
3
Revoke tokensPer-source tokens are revoked. The co-worker can no longer read any source.
4
Export audit logFull action log exported for post-incident review. Co-worker is cold.
§04 · Prompts & data leakage
What we don't do with your prompts.
The leakage questions are real. Here are the three lines we won't cross.
No training on customer data
Your prompts, outputs, and data are not used to train a shared model. Period. Where third-party model APIs are used, we configure them with the no-training option enabled.
No shared model state
Your co-worker does not share memory or context with another customer's co-worker. Each engagement runs against an isolated configuration, in your tenant.
Response-time access logging
Every data access – what source, what fields, when – is logged at response time. If you ask "did the co-worker read this record on this date," the audit log answers it.
§05 · Security FAQ
The six questions we actually get.
Drawn from real CISO and security architect conversations during procurement. Open any one for the answer.
Where is the agent runtime hosted?
For sensitive workflows we recommend Model C (customer-hosted) – the agent runtime, credentials, data, and logs all run inside your cloud environment, behind your identity provider. For lower-risk workflows, Model A (Riyalabs-managed) or Model B (hybrid) may be appropriate. The model fits the data – not the other way around.
Do you train on our prompts or outputs?
No. Your prompts, outputs, and data are not used to train any shared model. Where third-party model APIs are involved, we configure them with the no-training option enabled and document this in the data-flow diagram we review with your security team pre-implementation.
How do we revoke if something goes wrong?
Every co-worker ships with an owner-controlled kill switch and a documented revoke path: toggle off → drain queue → revoke tokens → export audit log. No Riyalabs ticket required. The owner is a named human on your side, not us.
What audit evidence can we get?
An action-level audit log: every read, every prompt, every approval, every send – with the user, timestamp, scope, and prompt/tool version used. The log lives in your environment under Model C, and can be exported in a format your SIEM or audit tooling can ingest.
Do you have SOC 2 or ISO 27001?
Not yet. The trust posture on this page is a set of baseline design principles, not a third-party attestation. If your procurement process requires SOC 2, ISO 27001, HIPAA, or similar, tell us early – we'll decide together whether to delay, scope around it, or recommend a different partner. We'd rather lose the deal than mislead you.
Can the co-worker take action on its own?
For high-impact actions: no. Human approval is the design default. The co-worker can read, draft, sort, and recommend – but anything that changes a record, sends a message externally, or moves money waits for a named approver on your team. The approval gate is the feature.
Get started
Bring your CISO to the first call.
We'll walk through the data-flow diagram, the kill-switch path, and the audit log for your candidate workflow – before any code gets written.