Your bots and agents need portal access too. Give it to them properly.
IRIS extends ZKeep to everything that is not a person. Bots, RPA runners, AI agents and API callers get their own identities, their own scoped access and their own audit trail, separate from the staff they work alongside.
The ZYNC Payor Portal Access Layer
ZYNC gives healthcare organizations a centralized way to launch, secure and govern access to payor portals and other critical websites, without exposing credentials to end users.
Most automation reaches payor portals through a human's login.
It works until someone asks who did what. Then the answer is a staff member who was not at their desk, and nobody can separate the bot’s activity from the person’s.
Shared credentials
A bot running under a biller’s account inherits every portal that person can reach, long after the task it was built for.
Invisible activity
Automation traffic looks like human traffic in the logs, so usage reporting cannot tell the two apart.
Revocation that misses
Offboarding the staff member breaks the bot, and leaving the account open to keep the bot alive leaves access open too.
Five ways work gets done without a person at the keyboard.
Each one gets its own identity in ZKeep, scoped to the portals it needs and nothing more.
Bots
Scripted routines that log into a portal, pull a result and get out. IRIS gives each bot its own identity rather than borrowing a staff account.
- Named bot identities
- Portal-level scoping
- Credentials never exposed to the bot
RPA
Robotic process automation platforms drive the browser the way a person would. IRIS hands the session over without putting the password on the robot’s screen.
- Session handoff to the runner
- Works with your existing RPA platform
- Concealed credential environment
AI agents
Agents that decide what to do next need tighter limits than a fixed script. IRIS bounds what an agent can reach and records every portal it opens.
- Bounded portal scope
- Per-agent activity log
- Revocable in one action
API-enabled access
For teams building their own workflows, access is requested and released through the API rather than a browser, under the same provisioning rules as every other identity.
- Programmatic access requests
- Scoped service credentials
- Same audit trail as the UI
Separation of human and automation workflows
Human and non-human identities are provisioned, reported and revoked on separate tracks, so automation activity never hides inside a person’s usage.
- Distinct identity classes
- Split usage and audit reporting
- Independent revocation paths
Two tracks, one access layer.
Everything that reaches a payor portal runs through ZKeep. What differs is how the identity is created, reported on and taken away.
Human workflows
Staff, contractors and partner teams working portals directly.
- Identity comes from your identity provider over SSO
- Access follows the employee lifecycle
- Usage reported by user and by team
- Revoked at the IdP, closing every portal at once
Automation workflows
Bots, RPA runners, agents and API callers.
- Identity registered as a non-human account in ZKeep
- Access scoped to named portals for a defined purpose
- Usage reported separately from staff activity
- Revoked independently without touching a person's account
Register, scope, execute, evidence, revoke.
Register
The bot, agent or service is created as its own identity, never as a copy of a staff account.
Scope
You choose which portals it may reach and for what purpose. Nothing else is in range.
Execute
ZKeep opens the session and hands it over. The credential is never returned to the automation.
Evidence
Every portal opened is logged against that identity and reported apart from human usage.
Revoke
When the workflow retires, access ends in one action and the staff accounts around it are untouched.
The same security framework your people already run on.
Automation identities sit inside the ZKeep storage and encryption framework, with concealed credentials, audit logs and usage reporting. Nothing about automation gets a lighter standard than staff access.
Common questions
If something here is not covered, the sales team can walk the specifics against your own automation stack.
Does the bot ever see the portal password?
No. Credentials stay concealed, as they are for staff. ZKeep opens the session and hands it over, so the password is never returned to the automation.
Does this work with the RPA platform we already use?
IRIS is designed to sit in front of your existing automation rather than replace it. Bring the platform you run today and we will walk the handoff on a live portal.
Can we revoke a bot without affecting staff?
Yes. Automation identities are separate from human accounts, so retiring a workflow ends its access in one action and leaves every staff account untouched.
How do we tell bot activity apart from human activity in reports?
Usage and audit reporting treat the two identity classes separately, so you can show what automation did without it being folded into a person’s record.
Is API access available on every plan?
API-enabled access is scoped during contracting alongside the advanced integrations available on Enterprise. Ask the sales team what applies to your plan.
Bring the automation you already run.
Show us a bot, an RPA routine or an agent that touches payor portals today, and we will walk what changes when it has its own identity.