Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / Vanta Agent Explained: Monitoring, Limitations & MDM Alternatives

Vanta Agent Explained: Monitoring, Limitations & MDM Alternatives

The Vanta agent checks four things on a laptop: whether the disk is encrypted, whether a password manager is installed, whether antivirus is running, and whether the screen locks on its own. That is the entire job. It is a lightweight background program that reports those signals back to Vanta so your compliance evidence stays current without anyone emailing screenshots to an auditor.

Most of the confusion around it comes from one of two directions: people expect it to manage their fleet like a full device-management platform, or they worry it reads far more than it does. Neither is true, and the gap between those two assumptions is where this guide lives.

What follows covers what the agent collects, what it deliberately ignores, how it talks to the Vanta platform, how it stacks up against a full MDM, and which compliance frameworks the evidence ends up supporting.

Vanta Agent Explained

What Is the Vanta Agent?

The Vanta agent is a small program installed on employee computers to continuously confirm that each device meets a short list of security requirements. If you have seen it referred to as the Vanta Device Monitor, that is the same product under an earlier name. The two terms are interchangeable.

Under the hood, it runs a hardened build of osquery, an open-source framework that exposes operating system state as a queryable SQL database. Vanta ships a modified version that strips out the tables it considers risky, which is why the agent can read a disk-encryption flag but cannot pull your browser history or SSH keys.

It is read-only by design. It inspects configuration and reports back; it never changes a setting on the machine. Vanta positions it primarily for smaller fleets, generally companies running fewer than about 75 devices, where standing up a full management platform would be overkill.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

What Does the Vanta Agent Do?

The agent exists to turn a recurring manual chore — proving that every laptop is configured securely — into something that happens quietly in the background.

Continuous Device Monitoring

Once installed, the agent keeps tabs on the device’s security posture on an ongoing basis rather than at a single point in time. This matters because audits care about whether a control held throughout the period, not whether it happened to be true the morning someone took a screenshot. Continuous checks caught the laptop with encryption switched off last Tuesday.

Automated Compliance Checks

Each signal the agent gathers maps to a control your auditor wants evidence for. Instead of chasing employees for proof that their disk is encrypted, the check runs automatically, and the result flows into Vanta as evidence. The work that used to eat days of an onboarding cycle collapses into a background process.

Real-Time Security Posture Tracking

The findings appear in Vanta as pass or fail states against each requirement, so a security lead can see fleet-wide compliance at a glance. A device that drifts out of compliance surfaces quickly, which shortens the window between a problem appearing and someone noticing it.

What Information Does the Vanta Agent Collect?

This is the question employees actually care about, and the honest answer is reassuring: the agent collects security configuration, not content. It does not transmit passwords, environment variables, SSH keys, emails, or browsing history. It reads whether protections are switched on, not what you are doing with the machine.

Insider Note: The reason the agent cannot snoop even if someone wanted it to is architectural, not a policy promise. Vanta deploys a modified osquery build that removes the tables capable of reading sensitive content. The dangerous queries are not blocked at the dashboard; they are absent from the binary. That distinction is worth raising directly when an employee pushes back on installation.

Operating System and Version Details

The agent records the OS and version so Vanta can confirm the device runs a supported, patchable platform. An end-of-life operating system is a control failure in its own right, and this is how it gets flagged.

Disk Encryption Status

It checks whether full-disk encryption is active — FileVault on macOS and BitLocker on Windows. This is the single most universally required device control across every major framework, which is also why it is the one Linux check the agent does support.

Screen Lock and Password Policies

The agent verifies that the screen locks automatically after a period of inactivity and that a password or equivalent is required to get back in. An unlocked laptop left on a train is a textbook breach, and this control is the cheapest defense against it.

Antivirus and Firewall Status

It confirms that antivirus or endpoint protection software is installed and running. The point is not to endorse a particular product but to prove that some recognized protection is active and has not been quietly disabled.

Installed Software and Auto-Update Settings

To detect the controls above, the agent reads the list of installed applications — for example, to confirm a password manager is present — along with update-related settings. It is reading the inventory to verify protections exist, not building a behavioral profile of the user.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

How Does the Vanta Agent Work?

How the Agent Communicates with the Vanta Platform

After installation, the employee registers the device against your Vanta account, which links that machine to its owner. From then on the agent runs its checks locally and sends only the results — the pass or fail signals — up to Vanta over an encrypted connection. The raw system queries stay on the device. What travels is the verdict, not the underlying data.

How Often the Vanta Agent Runs Checks

The agent uses osquery’s scheduled-query model, meaning each check runs on a recurring interval in the background rather than continuously hammering the system. Results sync to Vanta periodically through the day, and the platform’s tests re-evaluate on a regular cadence so a freshly remediated device clears its failing check without anyone forcing a manual refresh. In practice, a fixed laptop usually shows green within hours, not at the next audit.

Install Vanta Agent

Getting Started with the Vanta Agent

Supported Operating Systems and Versions

The agent supports current versions of macOS and Windows, plus several Linux distributions — primarily Ubuntu and close relatives — on the condition that the device exposes a stable, unique hardware identifier. There is one significant caveat on Linux: the agent can only check disk encryption there. Screen lock, antivirus, and password-manager detection are not available on Linux, so those controls will need manual evidence or MDM coverage on Linux machines.

How to Install the Vanta Agent

Installation is a per-device download. The employee logs into Vanta during onboarding, downloads the installer for their operating system, runs it with administrator rights, and completes a short browser-based registration that ties the device to their account. No additional configuration is needed; the agent arrives ready to work with your account.

Pro Tip: Two avoidable issues cause most failed installs. The installer needs administrator permissions, so run it as admin from the start. It also opens a browser window to finish registration, which means a machine with no default browser set will hang and time out. Set a default browser before you begin, and temporarily pause aggressive antivirus that may block the install.

Assigning Device Monitoring Tasks to Personnel

Rather than chasing installs individually, you assign a “Require device monitoring” task to the relevant employee group in Vanta. With the prompt option enabled, employees are walked through installing the agent themselves, and the task passes automatically once their computer registers. For teams using an MDM instead, you can assign the same requirement without prompting for the agent.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Vanta Agent vs. Mobile Device Management (MDM) Solutions

The agent and an MDM solve overlapping problems with very different scope. The agent is a compliance-evidence sensor. An MDM is a management platform that can also enforce and remediate. Understanding where that line sits will save you from reaching for the wrong tool.

The agent reads configuration and reports it; it cannot push a fix. An MDM can lock a device remotely, enforce a policy centrally, and wipe a machine that has gone missing. At the same time, an MDM typically requires more infrastructure, more administrative overhead, and meaningful per-seat cost. The agent, by contrast, is included in Vanta’s platform and takes minutes to deploy.

The practical dividing line is fleet size and risk appetite. For a team of twenty, the agent usually provides everything a SOC 2 auditor needs at the device level. For a team of two hundred spread across multiple office locations, the inability to remotely enforce or remediate becomes a genuine gap — and that is where a full MDM earns its keep.

When to Use the Vanta Agent

Reach for the agent when you are a smaller or earlier-stage company that needs solid compliance evidence without the cost and administrative weight of a management platform. It is also the right tool for filling coverage gaps — such as the Windows laptops your macOS-only MDM cannot see.

When to Use an MDM Integration Instead

As the fleet grows, the limits of a read-only sensor start to show. An MDM lets you enforce configuration rather than just observe it, push fixes centrally, and manage devices at a scale where chasing individual installs stops being realistic. Larger organizations and anyone needing remote lock or wipe should lean on an MDM as the system of record.

Using Both Together

These are not mutually exclusive. A common pattern is to run an MDM as the primary monitoring source and keep the agent as a secondary option for devices the MDM does not cover. If a computer reports through both, Vanta simply shows both sources. You get the enforcement of the MDM where it reaches and the agent’s coverage everywhere else.

Integrating the Vanta Agent with Your Existing Tools

MDM Integrations Supported by Vanta

Vanta connects with several widely used MDM platforms, including Jamf, Kandji, and JumpCloud, configured from the Integrations page in your dashboard. When an MDM is connected, devices it manages stay visible for monitoring without the agent installed, and unmonitored-device tracking adjusts accordingly. The choice between sources is yours to set per task.

Viewing and Managing Company Computers in Vanta

The Computers page is the single view of every device under monitoring, whether the data comes from the agent or an MDM. Each row shows a machine, its owner, and a column of check marks or X’s — one per security control. A green check means the control is met; an X means it is not. Clicking a user opens their fuller profile, including onboarding and access status alongside their device details.

Vanta Compliance Frameworks

Which Compliance Frameworks Does the Vanta Agent Support?

A clarification first, because this is where expectations run ahead of reality. The agent does not “support a framework” the way a product supports a file format. It supplies one category of evidence — endpoint security configuration — that maps to specific controls inside many frameworks. The frameworks themselves are far broader, covering policies, access management, vendor risk, and much more that has nothing to do with a laptop.

SOC 2

SOC 2, defined by the AICPA, is built around five Trust Services Criteria, and the device controls the agent checks feed directly into the Security criterion. Encryption, access control, and endpoint protection evidence are routine asks in a SOC 2 audit, and the agent automates the device-level portion of that.

ISO 27001

ISO/IEC 27001 is the international standard for information security management systems. Its Annex A controls include explicit expectations around endpoint security and cryptography, and the agent’s encryption and protection checks line up with those control objectives.

HIPAA

For organizations handling protected health information, the HIPAA Security Rule, administered by the U.S. Department of Health and Human Services, requires safeguards for electronic PHI. Device encryption and access controls are core technical safeguards, and the agent provides ongoing evidence that they are in place.

GDPR

The General Data Protection Regulation requires appropriate technical measures to protect personal data, with encryption named explicitly as an example in Article 32. The agent’s monitoring helps demonstrate that devices touching EU personal data meet that bar on an ongoing basis.

FedRAMP

FedRAMP governs cloud services used by U.S. federal agencies and is the most demanding of the group by a wide margin. Worth flagging: in 2026 the program shifted its core terminology, now describing approved services as FedRAMP certified rather than authorized. The agent’s device evidence is a small input into a far larger continuous-monitoring obligation here — not anything close to the whole picture.

Important: Installing the agent and turning every check green does not make you compliant with any of these frameworks. The device controls are one slice of evidence among dozens. Treating a fully green Computers page as “we passed SOC 2” is the most common misread of what the agent actually buys you.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Conclusion

The agent is a focused tool that does one job well: it keeps your device-security evidence current and honest without manual effort. It reads configuration, never changes it, and reports only verdicts rather than content. For smaller fleets it can carry the device-monitoring load on its own; for larger ones it works best as a complement to an MDM. Match it to your fleet size and your framework’s real requirements, and it quietly removes one of the more tedious parts of staying audit-ready.

Frequently Asked Questions About the Vanta Agent

Is the Vanta Agent the Same as the Vanta Device Monitor?

Yes. They are two names for the same software. Older documentation and some installers refer to the Vanta Device Monitor, while the agent is the current name. There is no functional difference.

No. It does not transmit passwords, emails, browsing history, environment variables, or SSH keys. It reads security-configuration flags — such as whether encryption is on — and reports the results. The sensitive osquery tables are removed from the build entirely.

Yes, and this is a useful point to share with skeptical staff. Because the agent runs osquery, a technically inclined employee can inspect the exact set of queries it executes on their machine using the agent’s command-line tools. Nothing about what it checks is hidden.

The device shows an X against the failing control on the Computers page, and the corresponding Vanta test flags as failing. Remediation is usually straightforward — for example, switching encryption back on — and once the agent’s next check picks up the fix, the status clears on its own.

Partially. The agent runs on several Linux distributions, mainly Ubuntu and close variants, but it can only check disk encryption there. Screen lock, antivirus, and password-manager detection are not supported on Linux, so those controls need manual evidence or an MDM for Linux devices.

The agent includes a built-in diagnostic tool — run via its command-line interface as vanta-cli doctor — which checks for common problems and reports what it finds. On Windows you run it from an administrator command prompt. The device also appearing on your Computers page is the simplest confirmation that it is reporting.

It can be pushed to many machines, including through MDM-delivered install scripts, but Vanta recommends it mainly for fleets under roughly 75 devices. Beyond that size, a dedicated MDM is the better backbone, with the agent filling gaps the MDM cannot reach. Scale is exactly the line where most teams graduate from the agent to an MDM-first setup.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

SOC 2 and ISO 27001 Engagement

After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information

The EU AI Act’s transparency requirements take effect on 2 August 2026, and most of the companies they cover still think the rules are not their problem. Article 50 applies to any business that publishes AI-generated content or runs an AI system that talks to people in the EU. That includes the marketing team generating campaign images and the support team running a chatbot. It also covers the AI agents you’ve wired into customer email. Penalties reach €15 million or 3% of total worldwide annual turnover, whichever is higher, and you don’t need an office in Europe to be in scope. If your content or your chatbot reaches EU users, the obligations reach you. In a nutshell: if you publish AI-generated images or video, deploy chatbots or AI agents that interact with EU users, or publish AI-written text on matters of public interest, then yes, the EU AI Act applies, starting 2 August 2026. A quick word on the “AI Act delay” headlines. The Digital Omnibus package did push the high-risk system deadlines back, in some cases by more than a year, but it did not move the deployer obligations in Article 50. Companies that read those headlines and stood down their AI Act work made an expensive mistake, because the rules most likely to touch an ordinary business are the ones that stayed on the calendar. What Article 50 Actually Requires Article 50 of the AI Act sets out transparency obligations in four situations. In plain English: Tell people when they’re talking to AI. Systems designed to interact directly with people — chatbots, voice assistants, and AI agents — must make clear that the user is dealing with AI, unless that’s already obvious. Mark AI-generated content so machines can detect it. Providers of generative AI systems must mark outputs in a machine-readable format, typically through metadata and watermarking, so the content is detectable as artificially generated. Label deepfakes. Anyone deploying AI to generate or manipulate image, audio, or video content that resembles real people, places, objects, or events, and could falsely appear authentic, must disclose that the content is artificial. Label AI-generated text on matters of public interest. Text published to inform the public must carry a label if AI-generated or manipulated, unless a human reviewed it and a person or organization holds editorial responsibility for it. Article 50 also covers emotion recognition and biometric categorization systems, which carry their own disclosure duties. Far fewer businesses run into those, so this article sticks to the four above. The distinction running through all of this is provider vs deployer. The provider builds or supplies the AI system. The deployer uses it professionally. Most companies reading this are deployers. If You Use AI-Generated Images Realistic AI images sit closer to the deepfake rules than most marketing teams assume. The Act’s definition covers content depicting people, objects, places, and events that could falsely appear authentic to a viewer, which describes a large share of what image generators produce for campaigns, social posts, and landing pages. So what does “clearly and distinguishably labeled” mean? The threshold is best described by its failures: a tiny disclosure hidden in the website footer doesn’t qualify. Neither does a faint label on an image, a label that flashes for an instant in a video, or a disclosure buried in your terms and conditions. The label has to be visible right where someone sees the content, and it has to meet accessibility standards so people with disabilities can perceive it too. The Code of Practice proposes a standardized “AI” visual label, localized per language (“KI” in German, “IA” in French). It also draws a useful line between fully AI-generated content and AI-assisted content, with lighter requirements for the latter. A designer who used AI to extend a background is in a different position from a team publishing a fully synthetic image of a person who doesn’t exist. Important: The deepfake duty doesn’t care about intent. A flattering, harmless AI image of your CEO at an event that never happened is still a deepfake under the Act. Marketing teams generate this kind of content casually. From August, every one of those images needs a label. If You Deploy AI Agents or Chatbots The rule itself is simple: people must know they’re dealing with AI. The provider carries the design obligation, but as the deployer you’re the one putting the system in front of your customers, and you’re the one an EU regulator will contact if your branded assistant pretends to be human. The Act contains an exception for cases where it’s “obvious” the user is talking to AI, judged from the perspective of a reasonably well-informed and observant person. Don’t lean on it. What’s obvious to your product team isn’t obvious to every customer, and the human-sounding voice agents and email-writing AI agents rolling out right now are designed specifically to not feel like software. If an AI agent negotiates a renewal over email or handles a support ticket end to end, disclose it. Pro Tip: Put the Disclosure at the Start of the Interaction Put the disclosure at the start of the interaction, in the interface itself: “You’re chatting with an AI assistant.” A line in your privacy policy doesn’t meet the standard, and a disclosure that appears after the conversation ends is worthless. For voice agents, say it up front in the greeting. What Your AI Vendors Owe You The machine-readable marking obligation in Article 50(2) sits with providers — the companies supplying your generative AI tools. The final Code of Practice expects providers to apply at least two layers of marking where necessary, such as embedded metadata combined with watermarking, and to offer detection mechanisms so deployers, authorities, and researchers can verify whether a piece of content came from AI. One timing caveat: the Digital Omnibus gives generative AI systems already on the market before 2 August 2026 until 2 December 2026 to comply with the marking requirement. Every other Article 50 obligation stays on

How Axipro Guided Technovative Solutions & DigiProd Pass to ISO 27001