I was looking forward to using Fable for cybersecurity work, but kept getting bumped to Opus… Signed my org up for CVP, went through the trouble of procuring a separate team plan from our main org as Anthropic can only disable cyber safeguards for an entire org and not individual users…
After months of trouble dealing with KYC and procurement I finally got CVP for my security org and today I found out that CVP (which is what removes cyber safeguards) does not apply to Fable…
So yeah, unless you’re a Project Glasswing member, there’s no using Fable (which with Glasswing is Mythos) for security work… Absolutely useless…
Didn’t they just sign some “we must use AI for cyber defense before the bad guys do” and then they artificially cap us by not allowing Cyber-unlocked Fable…
“Treat the agents like coworkers” - I’m working on this exact problem with daevix.com
Unique identity, dedicated and isolated compute, all ingress and egress monitored and audited as if I suspected the coworker (the agent) was secretly a DPRK spy.
I’ve heard from people inside Google that they’re prohibited from using anything but their own models. AlbertaTech on YT, ex-Google working on YT said in a video that right before she quit someone had threatened to quit if they couldn’t get access to Claude Code
The one thing I wish they’d support is multiple zones and an RBAC system to grant certain users access to specific zones. If they’d offer that they’d be a serious contender to replace Cloudflare and AWS/GCP DNS
I’d be curious how they’ve solved the attribution/provenance/identity problem here. Are instances of Claude Tag, across channels, sharing the same identity? Can I grant one instance access to a range of AWS roles and another instance access to other roles?
During an incident, how do I know which Claude Tag called AWS?
> Think of it as creating separate Claude identities for different uses: everything, including its memories, will stay scoped to the channels defined by the administrators. For example, a model set up for sales work won’t pass on memories to one set up for engineering; nor will it give engineers access to any sales data or tools. More information about provisioning access is available here (https://claude.com/blog/agent-identity-access-model).
Not really, and neither does the doc it links to. It explains the difference between a personal agent (that acts as you) and a multiplayer agent (that has its own identity).
But they walk all this back by saying that for PRs in GitHub it uses the upstream Claude for GitHub app - that is one installation of a GH app, which means one identity, one list of repos it can access. In the audit logs it will be impossible to see if it was Claude Tag from Channel Y or Claude Tag from channel X.
Arguably that’s a limitation of the abysmal state of machine identities in GH.
Agent identity and attribution continues to be important, but current systems makes it oh so difficult.
If the operator isn't around, then it shouldn't be approved. But yes, this is a problem, we have to ask the agent to retry after approval if its timed out. Currently the design philosophy is that the agent doesn't need to know anything about the firewall - no skill files, no code changes, completely transparent. But we're soon introducing a discovery endpoint that will allow the agent to know which services it has credentials for and tell the agent how to poll for HITL approval. This is an area of active development: https://github.com/denoland/clawpatrol/pull/666
Ah yes, the API will accept requests that doesn’t include the client attestation (or the fingerprint from src/utils/fingerprint.ts. At least it did a couple of weeks back.
They are most likely using these as post-fact indicators and have automation they kicks in after a threshold is reached.
Now that the indicators have leaked, they will most likely be rotated.
> Now that the indicators have leaked, they will most likely be rotated.
They can't really do that. Now they have no way to distinguish "this is a user of a non updated Claude code" from "this is a user of a Claude code proxy".
Hi all, Ishaan from LiteLLM here (LiteLLM maintainer)
The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8. Those packages have now been removed from PyPI.
We have confirmed that the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow.
All maintainer accounts have been rotated. The new maintainer accounts are @krrish-berri-2 and @ishaan-berri.
Customers running the official LiteLLM Proxy Docker image were not impacted. That deployment path pins dependencies in requirements.txt and does not rely on the compromised PyPI packages.
We are pausing new LiteLLM releases until we complete a broader supply-chain review and confirm the release path is safe.
From a customer exposure standpoint, the key distinction is deployment path. Customers running the standard LiteLLM Proxy Docker deployment path were not impacted by the compromised PyPI packages.
The primary risk is to any environment that installed the LiteLLM Python package directly from PyPI during the affected window, particularly versions 1.82.7 or 1.82.8. Any customer with an internal workflow that performs a direct or unpinned pip install litellm should review that path immediately.
We are actively investigating full scope and blast radius. Our immediate next steps include:
reviewing all BerriAI repositories for impact,
scanning CircleCI builds to understand blast radius and mitigate it,
hardening release and publishing controls, including maintainership and credential governance,
and strengthening our incident communication process for enterprise customers.
We have also engaged Google’s Mandiant security team and are actively working with them on the investigation and remediation.
We were not. I reached out to the team at BerriAI to offer my assistance as a security professional, given that they requested help from security experts.
After months of trouble dealing with KYC and procurement I finally got CVP for my security org and today I found out that CVP (which is what removes cyber safeguards) does not apply to Fable…
So yeah, unless you’re a Project Glasswing member, there’s no using Fable (which with Glasswing is Mythos) for security work… Absolutely useless…
Didn’t they just sign some “we must use AI for cyber defense before the bad guys do” and then they artificially cap us by not allowing Cyber-unlocked Fable…
Sigh…