A vendor wants read access to your employees' email, chat, calendar, and files. In exchange, it will deploy autonomous agents into your workspace that take actions on behalf of your staff.
If that sentence makes you uncomfortable, your instincts are calibrated correctly. This is a genuinely elevated risk category, and it combines three things that are individually manageable and jointly nasty: broad read access to unstructured employee communication, a non-deterministic system consuming that data, and write capability into production systems.
Here is what to interrogate, organized by the questions that actually surface problems.
1. Consent granularity: what exactly can it read?
The failure mode is scope creep at the OAuth boundary. A vendor requests broad Workspace scopes because it is easier to build against, then reads everything and filters later.
What to require:
Read-only scopes, minimum per source, with no write scope requested anywhere. Verify this on the actual Google consent screen rather than in the security questionnaire, since the two frequently disagree.
Per-resource approval below the source level. Connecting Gmail should not authorize all of Gmail. The employee should approve specific labels. Same for Drive folders, Chat spaces, Calendars, and project boards.
Consent persisted as enforceable records, not UI state. In Dactic's implementation, each approved resource writes a ResourcePermission record, and the sync layer can only read resources with an approving record. Unapproved resources are never accessed. Ask any vendor where consent is enforced. If the answer is the application layer only, a bug in the collector reads everything.
Revocation that takes effect on future syncs, surfaced to the employee directly in their own settings rather than requiring an admin ticket.
Worth flagging honestly: Dactic enables all resources by default during onboarding and requires employees to explicitly disable what they do not want shared. That is an opt-out consent pattern. It maximizes context capture and it is a real friction point with works councils and with employee trust. If you operate in a jurisdiction with strong workforce consultation requirements, raise this before signing and negotiate the default.
2. Employee privacy: can administrators read raw content?
This is the question that determines whether your deployment succeeds, and it is a security question rather than an HR one.
If employees believe an administrator can read their messages, they will restrict what they connect and withhold the informal knowledge that makes the product work. You get the surveillance liability without the benefit.
What to require:
A structural guarantee, not a policy commitment. The distinction is whether raw content is retained at all. Dactic's pipeline transforms evidence and does not retain originals post-transform, and no administrative screen renders raw employee logs, chats, or emails. That is different in kind from a vendor whose admin console could show raw content but has a permission flag disabling it.
PII detection and redaction before embedding generation and before any graph write. Ordering matters absolutely here. Redaction after indexing means the PII is in the index. Ask for the ordering in writing and ask what a known-PII test corpus demonstrates.
Redaction logging that records counts and categories only, never raw values, so the audit trail does not become the leak.
3. Multi-tenant isolation: where is it enforced?
A vendor hosting synthesized knowledge from multiple customers centrally has concentrated a great deal of institutional knowledge in one place. Cross-tenant leakage here is not an email address exposure. It is one company's operational playbook surfacing in a competitor's agent output.
What to require:
Isolation at the query layer rather than the application layer, across every store. Dactic scopes all data by organization at the query layer across both relational and graph stores. Application-layer scoping means one missing filter in one endpoint produces cross-tenant exposure.
Automated isolation tests in CI. Not a one-time review. A test suite asserting that queries from one organization never return another's records, running on every commit.
A documented review of every data-access path, with gaps remediated and retested. Ask for the review, not the summary.
4. Prompt injection: the control that gets skipped
This is the risk category most specific to agent architectures and the one most commonly hand-waved.
Your agent ingests employee email. Someone sends an employee an email containing text designed to look like agent instructions. The content enters the pipeline as evidence. If evidence and system instructions occupy the same trust boundary, an external party just wrote instructions for an agent operating inside your workspace.
What to require:
Explicit separation of untrusted evidence from system instructions at the prompt-assembly layer. Ask specifically how ingested content is delimited and whether the separation is tested adversarially. Dactic treats this as a named HIGH-severity risk with defenses layered across filtering, trust separation, bounded permissions, and execution caps rather than relying on any single control.
Filtering before indexing, which reduces injection surface as a side effect of noise reduction.
Bounded, audited agent permissions so a successful injection has limited reach. Dactic's platform guarantees are that agents act only within granted permissions, operate in the owner's permission context, cannot delete items or data, and require admin permission to deploy or manage. Default permission display on agent review cards is read-only unless write is explicitly required.
Execution caps on recurring agents. Loop agents ship with mandatory max-iteration limits, cost ceilings, and automatic pause-and-notify on anomaly such as repeated identical errors or spend spikes. The critical property is that anomaly detection does not depend on a human noticing.
Web search disabled by default, which closes a live exfiltration path from a successfully injected agent. Verify the default rather than the setting.
5. Grounding integrity: what stops bad context reaching production?
An agent grounded in incorrect synthesized context produces confident, cited, wrong business actions at scale. This sits at the top of Dactic's own risk register as a CRITICAL-rated risk, which is the correct assessment.
What to require:
A mandatory human approval gate before any content becomes authoritative. In Dactic's model, playbooks are generated in PENDING_REVIEW and lexicon terms sit in inferred or needs review status. Nothing in review grounds a live agent. A Champion reviews each policy point against its cited evidence.
Evidence citations on every policy point, so review is verification against source rather than plausibility judgment.
Contradiction detection that flags for human reconciliation rather than auto-resolving. Silently picking a winner between conflicting inputs produces a knowledge base that is confidently wrong, which is worse than one that is openly uncertain.
A pre-deploy validator that blocks on spec violations rather than warning about them. Dactic's blocks on missing instruction sections, unbound dynamic values, missing board or trigger, undeclared permission scope, unsupported context formats, and any PII or raw logs in context.
Model version pinning with a regression suite re-run on provider updates. An upstream model update silently changing pipeline behavior is a real failure mode, and pinning plus regression testing is the only defense.
6. Encryption, secrets, and integrity
Table stakes, but verify rather than assume.
- OAuth tokens encrypted at rest. Dactic uses Fernet.
- AES-256 at rest for stored data.
- TLS in transit on every endpoint.
- Secrets in a managed secrets service, no plaintext credentials in source. Dactic uses AWS Secrets Manager.
- Webhooks signed and verified. Dactic uses HMAC-SHA256 with per-endpoint secrets. Ask what happens to a tampered payload and require a demonstration.
- Server-side role enforcement on every request, never client-enforced, with automated RBAC tests per role.
7. Audit and forensics
What to require:
Immutable audit events for every privileged action with actor, action, target, and timestamp. Evidence reads, playbook approvals, scope grants, refresh runs. Dactic's log captures entries at the granularity of a named agent reading a specific number of items on a specific board.
Filterable and exportable logs, since an audit log you cannot query during an incident is a compliance artifact rather than a security control.
Sufficient retention for both forensic and compliance needs.
8. Compliance posture and the duty that lands on you
Read this section carefully, because it contains the obligation most buyers discover late.
Controller and processor split. Dactic is controller for account, billing, and administrative data, and processor for connected source content, interview data, and derived evidence. Confirm the split is documented and that a DPA is on offer with SCCs or UK IDTA where applicable.
The workforce notice duty is yours. Processing employee communications is workplace monitoring under GDPR. Dactic's risk register rates processing without lawful basis or required workforce notice as CRITICAL, and allocates the notice and consent duty contractually to the customer. Dactic operates an onboarding legal sign-off gate requiring attestation of lawful basis and completion of any required workforce notice before first sync.
That gate protects the vendor. It does not do your works council consultation, your employee notice, or your DPIA. If you operate in the EU or UK, budget for that work before you budget for the deployment.
Data residency. Current deployment is single-region in us-east-1, with a warm-standby DR region and an EU residency cell on a phased roadmap. If you have a hard EU residency requirement today, this is a gap rather than a control, and you need the timeline in a contract rather than a roadmap slide.
SOC 2. Type II is on the roadmap and not yet obtained. Controls exist and map to the framework. Attestation does not. If your procurement process requires a current SOC 2 report, this is a blocker today. Ask for the audit date and treat the answer as a commitment.
Model provider terms. Confirm contractual prohibition on training on customer data, with all providers, in writing, and confirm that periodic terms review is somebody's named job.
9. Availability targets
Ask for numbers, not adjectives.
Current stated targets are platform RTO within four hours and RPO within fifteen minutes at MVP, tightening toward one hour and five minutes at GA as the DR posture matures. Critical data stores run Multi-AZ with automated backups, point-in-time recovery, and cross-region backup replication.
Then ask the question that separates targets from capabilities: when was the last restore drill, and what were the measured timings? Dactic commits to quarterly restore drills and DR failover game-days with results logged. Request the most recent results. An untested RPO is a hypothesis.
The compressed version
If you have one meeting, ask these eight:
- Show me the actual OAuth consent screen and every scope requested.
- Can any administrator, under any configuration, view an employee's raw email or chat content?
- Is PII redaction before or after embedding generation, and what does your PII test corpus show?
- Is multi-tenant isolation enforced at the query layer, and are the tests in CI?
- How is untrusted ingested content separated from system instructions, and has that separation been adversarially tested?
- What blocks incorrect synthesized context from reaching a live agent, and is the gate mandatory?
- What are your RTO and RPO, when was the last restore drill, and what were the measured timings?
- Do you have a current SOC 2 Type II report, and if not, what is the audit date? Answers that are specific, including specific admissions of gaps, indicate a vendor that has done the work. Answers that are reassuring and general indicate the opposite.
A vendor volunteering its own critical risks is giving you something more useful than a clean questionnaire. Dactic's risk register rates its own top three risks as CRITICAL and names them: erroneous synthesized context reaching live agents, processing without proper workforce notice, and channel concentration on a single platform partner. Ask for that document. Whether a vendor will show it to you is itself informative.