How Do You Give an AI Agent Safe Access to a Legacy System?
AI agents can file claims, update records, and complete multi-step workflows today. The systems where that work actually happens, insurance platforms, ERP portals, utility dashboards, were built for a person clicking through a screen, not a machine calling an API. Deck exists because this specific gap, legacy system integration for AI agents, needs a different security model than connecting to a modern API ever did. Giving an agent safe access to a legacy system comes down to four problems: authentication, permission scoping, auditability, and failure handling. Get those four right and the integration is safe regardless of how old the target system is.
Why Is Legacy System Access Harder Than a Modern API?
Legacy system access for an AI agent means operating a web or desktop interface that was designed for a human, with no OAuth scopes, no rate limits, and no built-in action log. A modern API makes access explicit: you define scopes, the API enforces them, and every call is logged automatically. Legacy systems offer none of that. Authentication was not built with machine access in mind. A user can either log in or they cannot, with no granular permission layer in between. Session state lives in browser cookies, not tokens. To a legacy system, a human and an AI agent look identical the moment either one is authenticated. That gap produces three concrete risks: credentials that are hard to scope safely, write actions that are hard to roll back, and no native record of what happened. Deck's approach to legacy system integration is built to close all three at once.
What Is the Right Access Model for an AI Agent?
The safest model is user-permissioned access, not a shared service account. Deck is a computer use agent platform that automates workflows by operating any web interface directly, so the agent acts with a specific user's credentials and permissions rather than a generic account with broad reach. Under user-permissioned access:
- The agent inherits exactly what that user can see and do, nothing more.
- Each user's session is independent, so one compromised credential does not expose every user's data.
- Actions are attributable to a specific user and a specific agent session.
- Access is revoked instantly the moment a user withdraws consent. This is the access model Deck runs by default. It respects the permission structure the legacy system already has instead of trying to invent a new one on top of it.
How Do You Separate Read Access From Write Access?
Read and write access carry different risk profiles, and legacy system integration projects that treat them the same tend to get burned. A balance lookup can fail with no consequence. A submitted form on an insurance portal can be difficult or impossible to undo. Build and validate read access first. Data extraction, status checks, and document downloads carry low risk even when something goes wrong. Only extend the agent to write access, form submissions, payment initiation, record updates, once read access is proven reliable, and pair every write action with:
- Confirmation before execution: the agent verifies the action against the intended outcome before submitting.
- A documented undo path: know in advance whether the target system supports reversing the action.
- Explicit logging: capture exactly what was submitted and when. Deck enforces this distinction at the infrastructure layer, so a task scoped to read access cannot silently escalate into a write action against the legacy system.
Why Use Individual Credentials Instead of a Shared Service Account?
Shared service accounts are a common shortcut, and a risky one. Every action taken through a shared account shows up as the same generic identity in the target system's logs, which makes individual attribution impossible. A compromised service account exposes the entire integration, not one user's access. Service accounts also tend to carry broader permissions than any single user needs, with no way to scope them down. Deck connects each end user's own credentials or an authorized token, so agent actions stay attributable to the person who granted access. If one user's session needs to be shut off, it does not touch anyone else's.
How Narrow Should the Agent's Task Scope Be?
An AI agent should never get open-ended access to a legacy system. It should get one task: read this balance, submit this form, download this document. The session opens, completes that task, and closes. Long-lived sessions with broad access are both a security risk and an operational headache. Short, targeted sessions are easier to retry, easier to log, and easier to debug when a step fails. Deck runs every agent task this way by default, which is part of why legacy system integration through Deck does not require standing infrastructure per portal.
Where Does the Audit Log Come From if the System Has None?
Legacy systems rarely offer API-level logging, so the integration layer has to build its own record. A complete audit log captures which user's credentials were used, what the agent was instructed to do, what screens it navigated, what data it read or changed, and the timestamp and outcome of every action. This log is not optional. It is the evidence your team needs when something goes wrong, the debugging tool for a failed task, and the compliance record if a user disputes an action. Deck logs every session by default and makes each one replayable step by step, which removes the need to build this logging layer from scratch.
What Happens When the Agent Hits an Error?
Legacy systems fail in ways modern APIs do not. Sessions time out mid-task. Unexpected prompts appear, maintenance windows, consent dialogs, a surprise MFA re-challenge. Error states sometimes render as normal-looking pages instead of a machine-readable error code. A silent failure, where the agent reports success but actually hit an error screen, is worse than an obvious one. Every navigation step needs explicit failure detection, and if the agent cannot confirm success with certainty, it should treat the task as failed and surface that to a human. Deck builds this detection into every step of a session rather than assuming a page load equals success.
Should You Build This Yourself or Use a Platform?
Two paths exist for legacy system integration with AI agents. Custom browser automation with Playwright, Puppeteer, or Selenium works for a small number of stable portals when engineering time is available to maintain it. It becomes unmanageable fast once the number of target systems grows or a portal changes its UI, since RPA and hand-built scrapers both break the moment a selector moves. Deck removes that maintenance burden. An agent sends a task request to Deck's API with the right user authorization, and Deck handles session initiation, navigation, form interaction, data extraction, and error handling against the target portal. For teams operating across more than a handful of legacy systems, this is the difference between an integration project and an integration department.
What Does This Look Like in Practice?
A regional benefits administrator needed an AI agent to check enrollment status across eleven different carrier portals before answering employee questions, none of which offered an API. The team originally built browser scripts for the three largest carriers, and two broke within the first month when the carriers updated their login flows. They moved the workflow onto Deck. Each employee's enrollment lookup runs through Deck using the administrator's authorized credentials for that carrier, with MFA and session handling managed automatically. Lookups that previously took a staff member 10 to 15 minutes per carrier now return in under a minute, with a full session replay available for every request.
FAQs
Does Deck support write actions, not just reading data, on a legacy system?
Yes. Deck supports both read and write tasks, and enforces the same confirmation and logging requirements on write actions that a careful in-house integration would build manually.
Is Deck a replacement for building custom browser automation?
For teams connecting to more than a few legacy portals, yes. Deck handles session management, MFA, and error detection as a platform, which removes the maintenance work a custom Playwright or Selenium integration would require.
How does Deck handle MFA and CAPTCHA during agent authentication?
Deck manages MFA challenges, CAPTCHA patterns, and session continuity as part of connecting a user's account, so the agent does not stall on a verification step mid-task.
What is the difference between a shared service account and Deck's user-permissioned model?
A shared service account exposes every user's access if compromised and makes individual attribution impossible. Deck connects each user's own credentials, so access stays scoped to that person and can be revoked without affecting anyone else.
Does Deck log what the agent does inside a legacy system?
Yes. Every Deck session produces a full, replayable audit trail, including which screens the agent visited and what data it read or changed, which most legacy systems provide no native way to capture.
Ready to get started?
See how Deck can connect your product to any system — no APIs needed.
Build my Agent →