There are so many accurate responses in this thread. Like many have mentioned, SOC 2 is indeed not a prescriptive framework. Much of the confusion behind SOC 2 stems from that fact. It allows you to customize your InfoSec program to your company's needs. As we know, this can vary from company to company, hence why I read so many correct ways of approaching this specific situation in the thread.
Why SOC 2? SOC 2 is primarily customer-driven (this is why it becomes so urgent on your org). Buyer's require their vendors to undergo these third-party audits for their own vendor security management. While they would love to take you at your word, they feel a bit better knowing that a third-party took a look under the hood of your InfoSec program.
Employee vs. Contractor The legal status of an employee vs. contractor doesn't really matter for SOC 2 or most other InfoSec frameworks. At a minimum, what they really care about is the individuals ability to access, modify, view or otherwise have an effect on production/customer data. If an individual has that ability, they are likely in-scope (this can mean a lot of things). If an individual is indeed in-scope for your audit, they should follow your InfoSec program. You can always have carveouts for certain scenarios (for example, background checks are illegal in many countries so you may exclude them for individuals in those countries).
Company Policy What this all comes down to is the policy that the company has put in place. Does the company require all employees and contractors regardless of access to have hard drives encrypted without any carveouts? If so, then the company must follow that practice, or they will risk get an exception on their SOC 2 audit report. SOC 2 has some minimum standards that auditors look for but ultimately the company sets its controls and policies (if they are barebones they might not get accepted). Auditors are human and since SOC 2 is not prescriptive, reasonable minds will differ as to what those minimums exactly are.
Common Recommendation This has been mentioned a number of times in this thread but what we typically see and recommend is that you treat all employees as in-scope (this makes it easier on the company so they don't have to make determinations about who should and shouldn't be in-scope) and then for all contractors, you create a carveout where if they don't have access etc to production/customer data then they are not in-scope. In this case, such contractors would not need to track things like hard drive encryption, rendering the need for the agent moot. This seems in-line with the original posters role, and we would typically not have our customers require this of such a contractor.
There is nuance needed to make some of these determinations. For example, a company could hire a contractor who only has access to source code. In this case, an auditor may say that this contractor is indeed in-scope since they have control to modify source code that is pushed to production, even though they don't have direct access to the production itself.
We can't speak to the Drata agent, but based on what we would expect, the organization in OP's question is most likely trying to simplify evidence gathering when it comes time for the audit. There are other ways to grab such evidence (manual screenshots), but they are time consuming. Based on OP's job description it doesn't seem like its necessary for OP to be in-scope in this scenario and therefore the organization shouldn't need to collect such data. However, as we mentioned, this organization could have more stringent policies and without more information there isn't a wrong or right answer here. What we can confidently say is that it isn't a hard SOC 2 requirement.