AgentConnect is designed for teams that want to orchestrate AI agents without surrendering oversight. The product's security posture is built around four things: being signed in, being scoped, being approved where it matters, and being recorded.
The app surface requires sign-in. Accounts are created with an email and password, and email verification is part of the account lifecycle. Passwords are stored the way the auth provider stores them — we do not invent our own credential store. Security-related mail comes from a distinct sender so recipients can recognize it, and auth links are single-use and time-limited.
People in a workspace have roles. Roles control who can create agents, approve actions, manage members, and change workspace settings. Admin-only surfaces are hidden for people who cannot use them, not merely disabled — a person who cannot see a surface does not get a "you can't do that" popover, they simply do not see the surface.
Consequential actions can require human approval before they happen. The approval flow shows what is being approved, who requested it, and the policy context. Approvals do not auto-resolve. If an approval expires, the product shows that as "Expired" and the work moves to a state that reflects what happens next. Rejections are recorded with a reason where the policy requires one, and the reason is part of the audit trail.
Actions that matter are recorded with actor, time, target, and outcome. The UI shows the trail, not just the current state. You can see who approved what, who disconnected a provider, who changed a password, and who created or canceled a task. The point is not to log everything — it is to make the consequential things visible and reviewable.
You can see the sessions and devices associated with your account and revoke the ones you no longer recognize. Sign-in alerts are sent for new sessions where the product is configured to send them. Alerts are factual and calm — they say what happened, not "your account is compromised" on every sign-in.
When you connect a provider you grant only the scopes the work needs. The product shows connection state, when the connection was last tested, and any reason a connection is not healthy. If a provider credential expires or is rotated, the product tells you what to do — reconnect, re-authenticate, or contact support — not just that something failed.
It does not expose secrets, full tokens, or raw provider errors in the UI, logs, toasts, or emails. It does not imply autonomous authority for consequential actions by default. It does not run export or deletion silently. It does not let one user's data leak into another user's view through a mis-scoped query.
The statements on this page are about what the product is designed to provide. They are not certifications unless and until the product is actually certified in a regime. If a visitor could reasonably infer a certification or compliance posture the product does not yet hold, the product qualifies it rather than overstating.
Replace the placeholder specifics with the actual auth provider, the actual session/device surface, the actual audit retention, and the actual provider-scoping model before launch.