In light of the recent letters our customers have received from the Department for Work and Pensions, we would like to clarify and provide reassurance to councils that, here at Govtech, we do not use robots or robotic processes in our service provision and delivery. Here, our Operations Director Nigel Phillips provides an explanation for Govtech customers, covering some uncertainties about the use of robots.

DWP letters addressing 'Use of robotics solutions'

Nigel Phillips, Operations & Finance Director, Govtech Solutions Ltd.

The DWP’s Local Authority Partnership, Engagement and Delivery (LA-PED) division have issued two letters regarding ‘Use of robotics solutions’, on 15^th February 2021 and 3^rd June 2021. The DWP letters discuss and constrain the use of solutions that involve giving robots access to DWP systems or to DWP data on external systems.

None of Govtech’s products or services make use of any robots, robotic solutions, or robotic process automation tools in either their development or their execution. The DWP letters addressing the use of robotic solutions do not impact the operation of eCAPTURE, webCAPTURE or UCDS.

In their letters, the DWP have not defined what they mean by ‘robotic solution’ or ‘robot’. They have probably not done so because these terms are commonly understood to refer to automated processes that are defined within, and operated by, a Robotic Process Automation tool.

Gartner defines Robotic Process Automation (RPA) as follows:

“Robotic process automation (RPA) is a productivity tool that allows a user to configure one or more scripts (which some vendors refer to as “bots”) to activate specific keystrokes in an automated fashion. The result is that the bots can be used to mimic or emulate selected tasks (transaction steps) within an overall business or IT process. These may include manipulating data, passing data to and from different applications, triggering responses, or executing transactions. RPA uses a combination of user interface interaction and descriptor technologies. The scripts can overlay on one or more software applications.”¹

Basically, RPA is a form of business process automation that is able to record, or be taught, tasks performed by a human on their computer, then replicate those tasks as if the human were reading the screen (known as “screen-scraping”) and operating the mouse and/or keyboard. Tasks that are typically suited to RPA are repetitive, high-volume processes that are governed by a simple set of rules and have defined inputs and outputs. For example, the process of onboarding a new employee could include a number of tasks like creating user accounts in back-office systems, setting up an email address and recording personal details in an HR system. RPA tools can be used to create robots to complete these tasks just as if a member of the IT department or HR department were operating the keyboard and mouse.

Inter-system data exchange (for example using file transfers, database scripts or APIs) and automated rules-based processing (every computer program is rules-based) does not constitute a robotic solution: rather a robot is a computer program that is accessing and/or updating another computer system by mimicking a human user. This robot needs to be logged in to the system on which the task is being performed and, as far as that system is concerned, there is no distinction between sessions operated by a human user and those operated by the robot. This is why many computer systems use CAPTCHA verification tests to prevent data being recorded or retrieved by robots:

²

The overriding characteristic of a robot is that it interacts with a computer system using the same user interface as has been designed for a human user (albeit that a screen, keyboard and/or mouse may not be physically present). To the computer system, the robot is just another logged-in user, reading (‘scraping’) the screen, tapping the keyboard and moving and clicking the mouse. (If an automated process would be unaffected by the adoption of CAPTCHA verification tests, it’s unlikely to be a robot).

Understandably, this gives rise to security concerns. Each (instance of a) robot either needs its own user account to log in or needs to be activated by a logged in user (who then, effectively, is giving control of their terminal to the robot). More significantly, the computer system being operated will have had its user interface designed for operation by a human (often a trained user), and so may well rely on a measure of human judgement or decision-making in the interpretation of data and choice of next action. The range of actions that might be permitted to a trained user may therefore be inappropriate for a robot that is ‘piggy-backing’ on that user’s login credentials. Such piggy-backing can be deterred by deploying CAPTCHA verification tests at random points in the user session, not just at initial login.

These security concerns are identified in the first DWP letter issued 15th February 2021. The DWP recognise that each individual robot would require its own Employee Authentication Service (EAS) token, just as if they were a human user, and also that new user roles would have to be created to limit the robot’s access only to necessary data. They also acknowledge that, whilst setting up such EAS tokens and user roles is not necessarily a ‘blocker’, the DWP would need at least two years to complete the work.

Their subsequent letter issued 3rd June 2021 addresses two further scenarios that could be viewed as temporary solutions pending any future work that the DWP might undertake to create EAS tokens and user roles for robots:

• ‘Direct Robot Access’ – where an authorised human user logs into the DWP systems and then activates a robot to transact on their behalf (the 'piggy-backing' scenario discussed above); and
• ‘Indirect Robot Access’ – where an authorised human user logs in the DWP systems, downloads such data as they are permitted, and then stores that downloaded data on a local system to which a robot has access using its own login credentials.

The letter clarifies that ‘Direct Robot Access’ will not be allowed. This is absolutely justified because the DWP’s systems will be unable to distinguish between a session in which the human user is transacting themselves and a session in which they have turned over control to a robot. The letter also describes a number of conditions that the DWP requires to be met in order to sanction ‘Indirect Robot Access’, i.e. where a robot is being given access to a non-DWP system into which downloaded DWP data has been copied.

In summary, the DWP letters discuss scenarios in which robots might be deployed in order to clarify which types of deployment are acceptable and which are not; they do not seek to extend the definition of ‘robot’ to non-robotic solutions. These scenarios do not apply to any of the technical processes or methodologies deployed in the delivery of Govtech’s services.

Footnotes

¹ https://www.gartner.com/en/information-technology/glossary/robotic-process-automation-rpa 

² https://www.drupal.org/project/captcha