Video: Inside the Cyber Verification Program: Tiers, Migration, and Best Practices | Duration: 5400s | Summary: Inside the Cyber Verification Program: Tiers, Migration, and Best Practices | Chapters: Welcome and Introduction (6.07s), CVP Program Overview (92.91s), CBP Verification Tiers (349.34s), Common Use Cases (1057.075s), Prohibited Activities (1997.185s), Productization Process (2029.605s), Access Tiers (2184.4s), Q&A Closing (2328.345s), Closing Remarks (2431.27s)
Transcript for "Inside the Cyber Verification Program: Tiers, Migration, and Best Practices":
Alright. Hi, everybody. We are going to get started with our inside the cyber verification program webinar. As quick introduction, I'm Zach DeVault. I lead Anthropic's product strategy and operations teams. Joining me today will also be Nathan Bailey, who leads product for our safeguards organization as well as Grant Rheingold from our applied AI team. Four things that we're gonna cover today. So first, I'm gonna give a quick overview of what the cyber verification program is. Nathan will then dig into the details of how CVP works in practice. Grant will then share a set of lessons and and best practices, from working with customers on their cyber use cases. And then at the end, we'll finish up, with a brief q and a. A few quick housekeeping notes before we get started. This session is gonna be recorded, and it will be distributed via email within twenty four hours so that everyone attending the call, has it. So no worries. If you miss something, you need to jump back to it. Second, if you've got any questions, no need to wait until the end of the webinar. You can ask them right away through the submit a question widget, which is on the right hand side of your screen, and we'll answer it as best as we can throughout. And then as I said, we'll also save time at the end for q and a. Lastly, please give us feedback from today's session. Rate this webinar by completing the survey, which will pop up at the end of the session. And so with that, let's go ahead and dive in. So, some quick context on why this program exists. Cyber is inherently dual use. The same capability that helps your team find and fix a bug can help an attacker exploit it. So the GA models that we ship are pretty conservative from a safeguards... A cyber safeguards perspective, and they block most offensive security work. And to be clear, a lot of defensive work doesn't need CVP Things like code review, patching known issues, and finding vulnerabilities in your own code all work on the GA models as they exist today. CVP is very specifically, for teams that need to go further. You get verified, and then we turn on the advanced cyber capabilities with fewer blocks in place. So why now? Here's what we've seen across 33 Glasswing partners as well as the... Our our own work that we've been doing on open source. 595,000 candidate vulnerabilities have been found, 208,000 of those were triaged, and 34,000 were confirmed as either high or of critical severity. And that's from a survey of only a subset of our partners, so that can be treated as a floor. The real number is ultimately quite a bit higher. Finding vulnerabilities has never been easier, and we know that the real challenge comes with verifying, prioritizing, and actually fixing them. And in Glasswing, we'd often see months go by between a bug being found and a bug getting fixed, and that is specifically the gap that we're trying to close and why we want these capabilities in the hands of defenders first. And that's where CVP comes in. So what is CVP? CVP is how verified security teams get access to our most capable models for cyber work. That includes both Mythos and all new models as we ship them. It's tiered or around the work that you're actually doing. For example, defending your own systems is a different risk profile than someone who is, for instance, red teaming someone else's. So here's what the program looks like at a high level. Four things that you can take away here. One, c v... CVP is available on cloud platform, Google Cloud Vertex AI, Microsoft... And Microsoft Foundry. On Amazon Bedrock, CVP is only available at launch for customers who are enrolled in enterprise frontier safeguards, aka DFS, but we're working on broader Bedrock support. Two, everyone at CVP gets access to Opus five five, Sonnet five five, Haiku five five, and Mythos five one with reduced safeguards. And if you've already got cyber access on an earlier model, you do keep it. Three, there are three access tiers, and I'll get into more detail on those on the next pay... On the next slide. But the access tiers are defense access, red team access, and specialized access. And then four on Glasswing, which I know many folks, have been a part of. We've now folded Glasswing into CVP. Existing Glasswing members move into specialized access, and they don't need reapproval for, for access to current models. So next, I'll walk through each of those three tiers in a little bit more detail. Great. So defense access is where we would expect the majority of you to land. It covers security teams at companies, nonprofits, universities, and governments. It also covers critical infrastructure operators of any size, so you could think a regional hospital or a city utility, as well as smaller security firms, open source maintainers, and researchers with a track record. We do aim to turn around applications for the defense access tier in a few days. Red team access is for in house red teams and pen test firms. Right now, it's orgs only, not for individuals. You do get defense access while we review, which will take a few weeks. And then lastly, we have specialized access, which is for the broadest use cases and consists of a small group of orgs authorized to test systems where failure could ultimately result in hurting people or disrupting markets. So think grids, telcos, interbank transfers, and flight systems. We review each one of these submissions in-depth in partnership, with the US government. So that's an overview of what CVP is and the access tiers at a high level. I'm gonna now pass it over to Nathan who is going to jump more into how CVP works in practice. Thanks, Zach. And hi, everyone. I'm Nathan. And I'm gonna start with what happens if you haven't been verified in CVP since a lot of you have probably run into this. So some quick context setting first. Like Zach mentioned earlier, cyber capabilities are dual use. And so to prevent potential cyber harms, we have classifiers checking every single request in real time, flagging any requests that fall into certain categories of dangerous cyber activities. Every... Everyday security work, gets through these classifiers with no CDP needed, and that covers secure code review, patching known issues, finding vulnerabilities in your own source code, and triaging alerts. Dual use and offensive cyber work, though, is blocked by default, which includes vulnerability, validation, malware analysis, pen testing, and red teaming. And our newest models are more capable at cyber work, so they've launched with more conservative safeguards. Moving on to what CVP actually provides. CVP is how verified teams get those default blocks reduced. We verify your organization and the person applying, and we place you into a tier based on the work you do. The classifiers then allow the category of work your tier covers, and work outside of your tier stays blocked, and then some activity is prohibited at every tier. We also monitor over time. So the program requires data retention, which lets us detect misuse and act quickly, and I'll come back to that in a few minutes with some more details on data retention. A common question we get is whether CVP gives you a different or stronger model. It doesn't. CVP adjusts the safeguards, and every tier includes the same models. So every tier gets cloud Mythos 5.1, Opus 5.5, Sonnet 5.5, and any new models we launch from here. Moving on. This is probably the slide I'd recommend screenshotting. So each row here is a kind of cyber work, and each column is a level of access. Default access needs no application and covers secure coding like code review, patching, and alert triage, defense access, adds defensive cyber work, SOC and incident response, malware analysis, and reverse engineering, detection engineering, and analyzing and validating vulnerabilities. Moving to the right, red team access adds authorized pen testing and red teaming, including adversary emulation, offensive tool development, and exploit validation. And then the last column here, specialized access, adds high risk work, like authorized testing of critical safety systems and critical infrastructure. The bottom row is prohibited everywhere. That includes things like mass destruction of data or devices, denial of service attacks, physical world damage, and extortion. And so these tiers are built around kinds of work. So the question to ask is, which row describes what your team actually does? A common question we get is, why am I in the tier that I'm in? There's one application and it covers every tier. So So you don't pick a tier when you apply. We place your organization into a tier based on what you tell us. So the most useful thing you can do is just be really specific about the work that your team does. And we look at the work itself and whether we can verify your organization and the person applying and whether you can attest to the security controls for that tier. And you can also check out our help center to see other eligibility factors that we consider. If you're in... If if the tier you're in doesn't fit your work, there are a few paths. It kinda depends on where you're coming from. So if we migrated you over automatically from the old CDP, that means you haven't actually applied under the new program yet. So the path is to apply in the verification portal and describe the work, that you need covered. And if you did already apply and expected a different tier or if you're blocked on work that your tier should cover, you can use our appeal form in the portal, telling us about your authorized engagements, and our team will take another look. If you were already in project last week or CVP, you don't need to apply again. Most members of those programs move automatically and get an email confirming their tier, but also might need to complete new KYC or KYB checks if they haven't already. Current CDP members move to defense access. For most of you, that's automatic. And once you have the tier, you'll just need to assign the grant to specific orgs or workspaces in the portal. And if your team does offensive testing, that's what red team access unlocks. And so existing CVP customers can apply for it through the verification portal. And like Zach DeVault mentioned, review may take a few weeks for Red Team access. Project Glasswing's work continues in the cyber verification program. Glasswing partners move into specialized access, keeping the access that they have today and don't need to reapply for any current or future models. If you have any outstanding legal terms to accept though through Glasswing, that is one thing to do before getting access in the new program. And this is a top question that we get. Your access on earlier models doesn't change in the new program. So if you haven't gotten set up in the new CVP yet, you still have reduced cyber blocks on older models from the previous CVP, like Opus 5. If you are not in the program yet, here's how to apply. There's one application. It lives in the verification portal, and it covers every tier. You tell us about your team's security work. We verify your organization and the person applying, and we place you in that tier. And then you attest to security controls for that tier. And once you're approved, an admin on your side assigns the access grant, which I'll walk through in a couple slides. And on timing, most applications are are placed in defense access, and we process those applications within a few days. Applications that call for red team access take a few weeks since, at least for now, we have a human reviewing every single one of these applications. And then applications that call for specialized access, Like Zack mentioned, these are reviewed in-depth with the US government, and can take a while longer. And so each tier has different requirements. The security controls scale with the work that each tier allows. The point here is to have some degree of confidence that access to these dangerous capabilities doesn't accidentally leak. And so defense access asks for identity verification and security attestations, and it's also the only tier open to individuals on pro and max. Red team access is for organizations and companies only. It adds on a few more requirements, including business verification, phishing resistant authentication, controlled credentials, and c based access. And then specialized access has the strictest controls, including short lived credentials, endpoint, and network controls, background checks for everyone with access and seat limits. There's one date to know if you're in defense access. Today, you need MFA turned on and API keys have to be replaced at least every seven days. But on December 15, you'll need phishing resistant MFA and no static API keys. So we recommend moving to workload identity federation now, or with. The full list is in the CVP security requirements article in the help center. And one last thing to add is every tier also requires data retention, and I'll cover that in a couple of slides. So getting approved isn't the last step. On most plans, your tier only takes effects only takes effect once an admin assigns the grant. So if you're approved and still getting blocks, then check this first. So in Claude Code... In Claude console, you assign the program to a workspace, and we recommend one grant per workspace. On Claude enterprise, you assign it to a custom role and add the approved users. Owners and admin, owners and admins don't get the grant unless they hold that role. And then on Team Max and Pro, there's nothing to do since access applies to the whole account. On a cloud provider like Vertex, Foundry, and Bedrock, you link the account in the verification portal, and the exact steps vary by provider, and they're all in the help center. Allow, like, five business days after approval on these surfaces, specifically for Mythos to to show up. And if you're blocked after all of that, check that the grant is assigned to you and that data retention is on for that workspace, and the work that you're doing actually falls inside your tier. So I wanna be direct about data retention. It's required for organizations enrolled in the program so that we can monitor cyber misuse. Retention is what makes reduced safeguards possible. It's scoped to your CVP traffic handled under your data processing terms, and it lets us investigate quickly if something looks wrong. There is one exception today. If your organization already has data retention exemptions for Claude Mythos 5.1 or Fable 5.1, you can use CDP with zero data retention or ZDR on all models in CDP. Longer term, the path is enterprise frontier safeguards or EFS. Once it's available, eligible organizations will be able to store data in cloud infrastructure they control, and you can register interest through the form linked in the health center. That's it for me. Over to you, Grant Rheingold. Hey, Grant Rheingold. I think you might be on mute. Thanks, Zach DeVault. Gotcha. Apologies. Sorry, folks. Great. Well, I'm Grant Rheingold. I'm excited to, to talk about some of the common use cases, that we've learned from talking to customers, these lessons from the field. So these on the screen are the use cases that the team brings the most often with the access that each one needs. So finding and fixing vulnerabilities in the source code you own works on default access with no application. Triage and validation of those findings is defensive work and sits in defense access along with malware analysis and reverse engineering, detection engineering and incident response. Authorized pen testing, red teaming, and adversary emulation sit in red team access and authorized testing of critical safety systems sits in specialized access. The point here to draw out perhaps is that one workflow can cross, these lines, maybe from default access to, defense access to red team access, for example, for, finding, validating, triaging, patching, and then red teaming, a vulnerability. So it's important to note which, use case falls into which level of access to which tier. A few things surprise teams when they look at the program. First is that a lot of security work genuinely needs no application at all. We showed in the the last slide... Last few slides that secure code review, patching known issues, finding vulns in your own secure... In your own source code, and then triaging alerts all runs on default access. So there is a lot you can do out of the box. The next is that most applications are placed in default... In defense access. And this also covers more than you would expect. So this, as mentioned includes analyzing and validating vulnerabilities, malware analysis, and incident response. The third thing is that closed scanning is a separate path. So any Claude enterprise organization that meets the cloud security requirements can run scans on DeVault without CVP. CVP governs direct model access. I think the most common misstep is asking for the broadest access by default. The key takeaway here is to pick the tier by the work the team does. So red team access and specialized access involve, like, Nathan was mentioning, deeper review and stricter controls, and they take longer to put into use. So the metric to watch is how long it takes to get each use case into production. It's important to treat these grants like any other privileged access. So your red team gets red team access, your SOC and detection engineers gets defense access, and your specialized access goes to the handful of people whose work really needs them. Developers really don't need a Grant since secure overview, patching, and alert triage work, all can happen on default access. And this helps keep exposure and compliance scope small, and it saves those limited seats especially for specialized access for the people who need them. The review takes time. So, with 10 out of 10, always recommend using that time. The best thing you can do is start by writing evals for each use case so you know what good looks like. This is something like taking a scenario, a task, from that scenario, applying the agents that you're building to that task, and then having a sense of what the expected outcome, looks like and a grader to evaluate that outcome. So you're really defining the test scenario for the agents to work on and proving the workload on the models and access you already have to record that baseline. Then when your tier is live, you can cut over to the newest models, update prompts using the migration guidance for that model, and rerun those same evals that you already have a baseline for because you use the time that you had while you were waiting for approval to build out those evals and understand what's improved, the additional scope, make sure everything works just fine. So teams that anchor on evals can tell quickly whether a change in model, prompt, or tier has helped or hurt, and then make the appropriate changes based off of that. I would very, very strongly recommend taking the time to write out evals. Even if you have a very quick process for application and review, evals will give you the confidence to iterate across different model classes and different tiers, so you can make sure to keep improving. There are two different things that can stop a request, and they each need a different response. So a classifier block is the safeguard decision about activity. It means that the work falls outside of what your access allows or that the classifier got wrong, that classification. So it's important to check the work against your tier and report blocks on your work... Or sorry. Report blocks on work your tier covers so that they can be reviewed. A refusal on the other hand is the model declining on its own judgment. This usually comes down to, prompt and the context it was given about the scope and authorization of what it was asked to do. The key takeaway from the field here is to build your harness to tell those two apart. Log each one of those and make sure to follow that cleanly. This can mean another model. This could mean a person or a human in the loop or continuing with the rest of the run. But designing thoughtful systems that can fail over safely and gracefully is critical to making sure that we have robust and deployable systems. One of the other tenants to, talk about before we get into Q&A is applications are per organization, and different parts of a company can sit in different tiers. Your organization can also hold more than one access Grant. So give each team the Grant that matches its work and keep each Grant in its own workspace role or Claude account. This mirrors, like, what Nathan was saying before, mapping the tier to the kind of work. We're mapping the tier to the kind of, workspace or team that's using that. So if a user ends up with several grants, the broadest one will apply. So keep memberships tight, and data retention is scoped to program traffic. So small dedicated workspaces keep that footprint small as well. As Nathan mentioned, retention is what makes reduced safeguards possible and lets us investigate quickly if something looks wrong. So bring in privacy and legal before you apply so retention retention is settled early. Those are most of the lessons I got from the field. I'm gonna, pop open now to q and a. Alright. We've got the whole crew here. So we have a few frequently asked questions that we'll address first. One that we get a lot is how does CVP interact with enterprise frontier safeguards or EFS? I covered this a little bit earlier, but just to cover it again, data retention is required for all customers enrolled in CVP. This is similar to how we require data retention for Fable 5.1. EFS is a way for customers to manage their own data rather than having it handled on the Anthropic side. And this is, like, the main exception to the data retention requirement for CPP. So EFS eligible customers that have been given DDR bridges for Fable 5.1 specifically and have that CDR bridge applied to CPP as well. So similar to covered models like Fable 5.1, EFS is the the way to, get an exception to the data require... The data retention requirement in CDP. If you're not enrolled in EFS, you can fill out an interest form that we will share. Can I productize models on any tier? Grant, you wanna take this one? Yeah. Happy to. So, yes, you can productize. It's available with approval. So you can fill out an application in the verification portal after submitting the main, CVP application. What's happening with Glasswing? Zach, you wanna take this one? Yeah. Definitely. So, Project Glass Wing's work is gonna continue through the CVP program. All Glass Wing partners have been moved into specialized access, and they keep the access that they have today. And then, obviously, last week last week, we launched our broader, cyber mission initiative focused specifically on helping critical infrastructure providers and, OSS maintainers, shore up some of their defenses. And so, both the the access program goes into CVP and then the mission related efforts, goes into the cyber mission work that Anthropic is pulling forward. Alright. And is the model different in each tier, Mythos or Fable? So each tier gives access to the same models, whether it's Mythos, Opus, Sonnet, even Haiku. And the tier itself unblocks different capabilities on every model. So the tiers are model agnostic. Each one will give some level of access to Mythos. Fable is just the name for the same model as Mythos, but with all of our safeguards on. So Fable isn't really relevant for CVP CVP gives access to Mythos with reduced cyber blocks. And is CVP available on Amazon,, Grant, you wanna take this? Yes. So today's CVP on Amazon Bedrock is only available to organizations with a data retention exemption for Fable 5.1, but broader Bedrock support is in progress. Great. I think we have some more questions rolling in. Let's go with, my organization holds more than one access grant. Who on my team is getting which? Grant, you wanna kick this one too? Yes. So your organization may hold more than one access grant. Like I was saying before, yes. We recommend assigning each team the grants that matches the work it does and keeping each grant in its own workspace, role, or cloud account. So, yes. In other words, if, we're talking about your red team, this is probably red team access, or, your SOC and detection engineers probably get defense access. And then for that really specialized work, that will be specialized access. So the key takeaway here is that, yes, you can and to really try to match the work to the team to the tier that you're talking about. Cool. Is there a difference in the approval process and review time between CVP defense access and red team access? Zach, you wanna take this one? Yeah. So most applications are automatically placed in the defense access tier, and we aim to respond to those within a matter of days. I think I think we said a few days. Applications that specifically request red team access often take a few weeks. In the intervening period, we give the user, or the the requesting party access, to defense access while they wait. And the reason for that is each red team access request is individually vetted by a member of our team. And I've seen a bunch of questions in the chat as well on, on individual access to red team. That is one, that we're evaluating. It's not available yet, but it's one that we're gonna evaluate towards, the future. So, more to come on that one. But right now, we have a large backlog that working... We're working through from an organizational perspective, to handle organization access to, to red team. Thanks, Zach. We were placed in defense access. How do we move to red team access, and how long does that take? Grant, you wanna answer this one? Yes. So many capabilities overlap across tiers. Defense, access covers vulnerability analysis and validation, plus malware analysis and incident response. So please assess whether that's sufficient for your defensive needs. As Nathan mentioned earlier, if you believe your needs require higher tier capabilities, please submit a request through our appeals form in the portal. Cool. One question is how does CVP activate on the Claude Max or Teams plan? Can I have all a separate individual grant? Yeah. So individual researchers with a track record of reported vulnerabilities, maintainers, bug bounty hunters are eligible for defense access. It's available on Pro Max team enterprise and API accounts. Red team and specialized access, are currently for organizations and companies only, like Zach just mentioned. You can access via, like, our first party offerings by signing into the verification portal with your Anthropic account, opening programs, and then choosing the cyber verification program in the programs tab. We've got... Is anything prohibited in all the tiers? I think we covered this, but, Grant, do you wanna touch on it again? Yeah. Just a quick touch point again. Mass destruction of data or devices, denial of service attacks, physical world damage, extortion, election interference, if interference or any request with stated malicious intent, won't be allowed. So, yeah, definitely definitely a set of things that are prohibited. Cool. And, yeah, we've got some more questions on the productization process. Zach, do you wanna cover what the productization process looks like? Yeah. Definitely. So productization has been there, all along with these existing CVP. We obviously announced several weeks ago or maybe maybe it's about a month and a half ago the ability to productize on Mythos. So, one, productization is only available with approval. It applies to all models, within the new CVP program from Haiku up up to the Mythos class models. And once you're approved for a tier in the CVP program, you can then fill out the productization application, which is is already there within the verification portal. Cool. Seeing some more questions about difference between models, specifically between Opus 5.5 and Mythos 5.1. So given Opus's, Opus five point five's increased cyber capabilities, It launched with pretty conservative cyber safeguards that block higher risk cyber work for general users. So cloud Opus 5.5 as well as Sonnet 5.5 and Mythos 5.1 are all covered by the new tiers. So applying will allow you to experience reduced blocks on all of those. In addition to Haiku 5.5, which has already reduced, cyber blocks, but the cyber verification program will reduce them even more. And then I had a follow-up question I saw from Peter on productization referring to service delivery. This is both for constrained product offerings and for managed services delivery. I'm using Vertex AI or Microsoft Foundry. How long will it take to get access? What's the typical review timeline? Grant, you wanna take this? Yes. So once approved, customers accessing through a cloud provider should expect about five business days for, Mythos access to be enabled on their account. Direct, so one p or first party API customers, shouldn't be affected by this lag. Cool. I think that's most of the meaty questions. I'm seeing one. What can I do without applying? Yeah. So everyone gets default access, which allows secure code review, patching known issues, finding vulnerabilities, and triaging security alerts. If you're only doing these things, you you shouldn't need CVP. It's it's possible that you'll get blocked via just, like, classifier false positives. No classifier is perfect, and we're always, working hard to reduce false positives on our cyber blocks. But, yeah, the the intention at least is if you're not doing kind of more dangerous dual use or offensive cyber activities, then you shouldn't need to apply for this program and and get verified. If an action is misclassified, how can I submit feedback to improve the classifier? We actually don't have an amazing, path for this right now except for customers with account managers, in which case it's super helpful to share feedback with your account manager, and and they'll share it with the relevant teams at Anthropic. But we're looking to provide better feedback mechanisms in the future. Is bug bounty work covered under defense access, or is red team access required? I can take this. Bug bounty work should should be totally fine in defense access. Cybersecurity companies, enterprise security teams, open source maintainers, bug bounty hunters, these are all supported in defense access. It's, it's not until you're doing the more kind of pen testing like activities, moving laterally through systems, avoiding detection, exfiltrating data, etcetera, that you'll need offense, or red team access. And... Yeah. So bug bounty work should be covered under defense. Can you clarify, is using Mythos 5.1 and Fable 5.1 effectively identical when using this program? It's a good question. So if you're in CVP, you should see Mythos 5.1 in the model picker in in relevant product surfaces, or should be able to call the Mythos string, like, model string. If you're in CVP, they will not be identical when using the program. You'll wanna call Mythos and not Fable. Fable will still have all of the, the full cyber blocks. We do that so that you can sort of choose whether to use, Mythos or Fable and be able to, have the cyber safeguards in place when you want them. So... Yeah. Again, the answer is no. It's not the same using Mythos 5.1 and Fable 5.1. You're gonna wanna use Mythos, for separate work. Last question here. How long will it take my application to be reviewed? I think we covered this. It it depends. I could take it. Yeah. It's it's, go ahead. it's a few days, for the defense access, a few weeks for red team access. And then, for specialized access, we obviously work in partnership, with the US government to do individual by individual approvals, and so that one will take a little bit more time. So we don't have a hard time frame for that, but we've got a great working relationship, and we move pretty quickly through that. Alright. Cool. I think we can close there. Zach, you wanna add add anything at the end No. That's? all. Thank you all for joining. I really appreciate the thoughtful questions. Please, if you've not had a chance to apply, please please do so. Again, the... This, webinar has been recorded, and, so everybody will have access to it and all the, answers that Nathan, Grant, and I was... Were able to provide. And please take the survey, at the end. I think that we're about to trigger that right now. All feedback is always welcome. So, genuinely, thank you so much for joining, and and appreciate you all, being partners with Anthropic. Thanks, everyone. Thanks, Paul.