Good point! We are working through the details of those sorts of use cases, and are thinking of ways to mitigate the risks posed. A lot depends on the characteristics of your particular background tasks, but here are a few ideas we’re considering:
- Grant background tasks limited access to data based on some applicable filter. Imagine your medical software sends a nightly summary of tomorrow’s appointments. Instead of giving the background task access to the entire database (including patient names and medical histories), grant it access to summary data about appointments which occur in the next 24 hours. In this example, there is still sensitive data at risk, but the scope is limited.
- Have temporally limited access for scheduled tasks. Can we scope them to only running for 30 minutes once a day?
- As a matter of practice, only run these types of jobs on machines that are isolated in a tightly controlled private network with an absolutely minimal attack surface.
We’re still working out how to express some of these scoping restrictions in practice, but the core idea here is that we should be able to mitigate overall risk by being more judicious about how we grant access.
