Security and data handling
Building an AI operator means giving it access to systems that hold your business. This page describes how Phronimos handles that access, what we can and cannot see, and where the practice is still being built out.
Principles
Phronimos never holds your passwords.
Access is granted through authorization flows you complete yourself. It is not collected, and it is not stored on our side.
Least privilege by default.
We request the minimum permissions a workflow needs, for the systems named in the statement of work, and nothing else.
Per-client isolation.
No client authentication surface touches another. Each engagement runs in its own isolated environment.
High-risk actions are gated.
Sends to your customers, payments, bulk changes, and deletions require approval from your named approver before an operator executes them.
We detect failures first.
Monitoring and alerting sit on our side of the line, so a broken operator reaches us before it reaches you.
Access ends when the engagement ends.
Every grant is revoked or handed back for revocation, data is returned or deleted per the agreement, and completion is confirmed in writing.
How does Phronimos get access to our systems?
System access runs through a managed authentication layer. Your administrator completes every authorization flow directly with the source system, whether that is your email provider, CRM, or messaging tool. The credential exchange happens between your business and that authentication layer. Phronimos never sees, receives, or stores your password or plaintext tokens at any point.
Tokens live in the authentication provider's encrypted storage with automatic refresh. At runtime, an operator presents a client-scoped identifier and the provider applies your token at call time. Where a system offers no standard authorization flow, the key is entered into the provider's own interface rather than anything Phronimos controls. Where the provider does not support an integration at all, a documented fallback governs transfer through a password manager or encrypted send, never plain email or chat.
After wiring, each integration is verified with a single read-only test call. Write access is exercised only inside workflow-specific procedures that carry their own dry-run gates.
What can an operator do without asking?
Managed operators run inside approved runbooks rather than as free-roaming generalists. Actions designated high-risk in your statement of work require approval from your named approver before execution. That list typically covers external sends to your customers, payments or financial commitments, bulk data changes, and deletions.
The same discipline governs Phronimos internally. Money, contracts, public posting, client contact, and credential actions require named human approval and are never autonomous.
What happens to our data?
Client data is used only to perform the engagement. No training on your data, no resale, no reuse across clients. Data categories, subprocessors, breach notification, and deletion terms are defined per engagement in a data processing agreement signed before work begins.
Your transcripts and workflow content stay out of our logs and internal reports except where the engagement requires it. Internal health checks reference filenames and statuses rather than content.
When an engagement ends, every access grant is revoked or identified for you to revoke on your side, data is returned or deleted per the agreement, and completion is confirmed in writing.
How do you know when something goes wrong?
Managed workflows carry monitoring and failure alerting as part of the retainer. Phronimos tracks failure counts, time to detect, time to recover, task success rate, and the share of failures found by Phronimos before the client noticed. A scheduled health check verifies pipeline agents, failure logs, data freshness, and connected-account status, including early warning on expiring or revoked grants, which otherwise surface only at the next operator call.
The commitment: when a managed workflow fails, Phronimos aims to know first, tell you promptly with a plain account of the impact, and log the incident and the fix.
Questions before you grant anything?
Ask them before the review rather than after. Nothing on this page changes once an engagement starts, and the full policy and data processing agreement are available on request.