Tag: policy

The SEC Just Quietly Surrendered in Its Biggest Crypto Battle

Posted on by faz_business


The crypto world’s biggest and most consequential legal war is finally over. Ripple Labs, a fintech giant, has just closed the book on its nearly five-year battle with the U.S. Securities and Exchange Commission, ending a fight that had become a proxy for the future of cryptocurrency regulation in America.

The surprise settlement is being hailed as a landmark victory for the crypto industry and a significant blow to the SEC’s controversial “regulation by enforcement” strategy.

The “SEC announces joint stipulation to dismiss appeals, resolving civil enforcement action against Ripple and two of its executives,” the regulator said in a statement on July 7.

What Was the Fight About?

Ripple is a company that uses its cryptocurrency, XRP, to make international money transfers faster and cheaper than traditional banking systems. In 2020, the SEC sued Ripple, alleging that XRP was an unregistered security. In simple terms, a security is an investment contract, like a share of stock. If a crypto token is deemed a security, it must follow the same strict registration and disclosure rules, a standard most crypto projects have not met. An SEC victory could have effectively outlawed XRP in the U.S. and set a precedent to cripple hundreds of other tokens.

On August 7, the fight officially ended. The SEC announced a “joint stipulation to dismiss appeals, resolving civil enforcement action against Ripple,” while Ripple agreed to drop its cross-appeal. The final judgment from the lower court—including a $125 million penalty—will remain in effect, but the war is over.

While Ripple is paying a penalty—$50 million—, the company is walking away with a far more valuable prize: a game-changing legal precedent. A 2023 ruling from Judge Analisa Torres dealt the SEC a major blow by finding that Ripple’s sales of XRP on public exchanges—where buyers are anonymous and not dealing directly with the company—did not qualify as securities transactions. That part of the decision remains intact.

This is a huge deal. It creates a crucial distinction that other crypto projects can now use in their own legal battles, potentially shielding them from the SEC’s claim of blanket authority over the market. By choosing to settle rather than risk having this ruling upheld by a higher court, the SEC has shown the limits of its “regulation by enforcement” playbook: its strategy of creating rules through individual lawsuits instead of issuing clear guidelines for the industry.

As Ripple’s chief legal officer, Stuart Alderoty, wrote on X, it’s “the end… and now back to business.”

What It Means for Main Street

While both sides can claim partial victories, the biggest winner is arguably Main Street, or the everyday investors and developers who have been caught in the regulatory chaos for years. The brutal legal battle forced a court to confirm that not all digital assets are automatically securities, especially when traded by the public. This provides a clearer, though still incomplete, set of rules. For investors, it reduces the risk that their holdings could be declared illegal overnight. For innovators, it provides a slightly clearer path to building compliant projects in the U.S., moving the industry one step closer to mainstream legitimacy.

Our Take

The SEC has spent years trying to define the crypto industry through litigation. The Ripple case shows that strategy is losing steam. The agency’s decision to settle rather than risk another courtroom loss could embolden other crypto companies to fight back rather than agree to quick deals. This marks the start of a new chapter in the crypto-Washington standoff, one where legal and political pressure may finally be forcing a long-overdue rethink of how America regulates digital assets.



OpenAI pledges to give U.S. AI Safety Institute early access to its next model

Posted on by faz_business


OpenAI CEO Sam Altman says that OpenAI is working with the U.S. AI Safety Institute, a federal government body that aims to assess and address risks in AI platforms, on an agreement to provide early access to its next major generative AI model for safety testing.

The announcement, which Altman made in a post on X late Thursday evening, was light on details. But it — along with a similar deal with the U.K.’s AI safety body struck in June — appears to be intended to counter the narrative that OpenAI has deprioritized work on AI safety in the pursuit of more capable, powerful generative AI technologies.

In May, OpenAI effectively disbanded a unit working on the problem of developing controls to prevent “superintelligent” AI systems from going rogue. Reporting — including ours — suggested that OpenAI cast aside the team’s safety research in favor of launching new products, ultimately leading to the resignation of the team’s two co-leads, Jan Leike (who now leads safety research at AI startup Anthropic) and OpenAI co-founder Ilya Sutskever (who started his own safety-focused AI company, Safe Superintelligence Inc.).

In response to a growing chorus of critics, OpenAI said it would eliminate its restrictive non-disparagement clauses that implicitly discouraged whistleblowing and create a safety commission, as well as dedicate 20% of its compute to safety research. (The disbanded safety team had been promised 20% of OpenAI’s compute for its work, but ultimately never received this.) Altman re-committed to the 20% pledge and re-affirmed that OpenAI voided the non-disparagement terms for new and existing staff in May.

The moves did little to placate some observers, however — particularly after OpenAI staffed the safety commission entirely with company insiders including Altman and, more recently, reassigned a top AI safety executive to another org.

Five senators, including Brian Schatz, a Democrat from Hawaii, raised questions about OpenAI’s policies in a recent letter addressed to Altman. OpenAI chief strategy officer Jason Kwon responded to the letter today, writing that OpenAI “[is] dedicated to implementing rigorous safety protocols at every stage of our process.”

The timing of OpenAI’s agreement with the U.S. AI Safety Institute seems a tad suspect in light of the company’s endorsement earlier this week of the Future of Innovation Act, a proposed Senate bill that would authorize the Safety Institute as an executive body that sets standards and guidelines for AI models. The moves together could be perceived as an attempt at regulatory capture — or at the very least an exertion of influence from OpenAI over AI policymaking at the federal level.

Not for nothing, Altman is among the U.S. Department of Homeland Security’s Artificial Intelligence Safety and Security Board, which provides recommendations for the “safe and secure development and deployment of AI” throughout the U.S.’ critical infrastructures. And OpenAI has dramatically increased its expenditures on federal lobbying this year, spending $800,000 in the first six months of 2024 versus $260,000 in all of 2023.

The U.S. AI Safety Institute, housed within the Commerce Department’s National Institute of Standards and Technology, consults with a consortium of companies that includes Anthropic, as well as big tech firms like Google, Microsoft, Meta, Apple, Amazon and Nvidia. The industry group is tasked with working on actions outlined in President Joe Biden’s October AI executive order, including developing guidelines for AI red-teaming, capability evaluations, risk management, safety and security and watermarking synthetic content.

Visual Studio Geeks | Policy enforced deployments for your Kubernetes resources

Posted on by faz_business


As your team starts to deploy resources to Kubernetes regularly, it becomes necessary for you as a cluster administrator to maintain good standards and consistency of the Kubernetes resources. Be it, ensuring all the resources have set of labels, or ensuring you only pull images from your enterprise container registry. Gatekeeper is a well known policy enforcement tool using Open Policy Agent (OPA) – which is a opensource, Cloud Native Computing Foundation (CNCF) project.

But did you know you can validate policies on your Kubernetes manifests before you deploy them on to the cluster? In this post, we will see how we can govern our deployments using Conftest and OPA policy agent.

However, Gatekeeper is installed on the cluster and thus ensures no policy is broken at deployment time. This means that any validation of policies happen only when you are trying to deploy resources to cluster. While this ensures that no resource violates the policy, you would like to know about these policies much earlier in your CI/CD pipeline. Doing policy validations much to the left of your deployment pipeline ensures your deployment going smooth when necessary.

This is where Conftest helps. Conftest relies on OPA and policies are written using Rego – thus the policies you write for Gatekeeper will be compatible with Conftest. But more importantly with Conftest, you can validate your local manifests against OPA policies locally and ensure your resources are compliant before you deploy them.

Installation

Installation is really easy if you are on Mac – For other platforms refer to the documentation

brew install conftest

Folder structure

By default, Conftest expects you to maintain your policies under policy folder at the same location as your Kubernetes resources. If you prefer a different path, you will want to pass it using CLI or set environment variable CONFTEST_POLICY.

📂 src
    📂 k8s
        📄 deployment.yml
        📄 service.yml
        📁 policy
            📄 replica.rego
            📄 labels.rego
    📂 app
        📄 main.ts
        📄 package.json

Writing Policies

As mentioned previously, policies are written in Rego. I struggled to write policies initially and constantly went back to documentation. However, once you write couple of policies, you will get a hang of it. Take a look at the simple policy to check every deployment has at least 2 replicas.

package main

deny_replicas[msg] {
    input.kind == "Deployment"                          # check if it is a Deployment
    input.spec.replicas < 2                             # And the replicas are < 2
    msg := "Deployments must have 2 or more replicas"   # show the error message and fail the test
}

input is the complete yaml document from our deployment yaml (see below) and we we are checking if kind is equal to Deployment. If its deployment, we move to next line in the constraint and check if spec.replicas is less that 2.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mynodeapi-dep
  labels:
    app: dep-k8s-nodejs-api
spec:
  replicas: 1
  selector:
    ...

You can write other policies similar to the one above to validate various aspects of Kubernetes resources. Let us see few examples.

This policy validates our resources have the required labels and fail if any labels from required_deployment_labels object are not found.

package main

import data.kubernetes

name = input.metadata.name

required_deployment_labels {
	input.metadata.labels["app.kubernetes.io/name"]
	input.metadata.labels["app.kubernetes.io/instance"]
	input.metadata.labels["app.kubernetes.io/version"]
	input.metadata.labels["app.kubernetes.io/component"]
	input.metadata.labels["app.kubernetes.io/part-of"]
	input.metadata.labels["app.kubernetes.io/managed-by"]
}

violation[msg] {
	input.kind == "Deployment"
	not required_deployment_labels
	msg = "Must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels"
}

Reference container images only from our enterprise Azure Container Registry

package main

deny[msg] {
    input.kind == "Deployment"
    some i
    image := input.spec.template.spec.containers[i].image
    not startswith(image, "myacr.azurecr.io") # validate images start with endpoint for our container registry
    msg := sprintf("image '%v' comes from untrusted registry", [image])
}

As you can see rules can be very powerful.

Testing

The command to test resources using Conftest is conftest test <PATH>. Since I would like to test all resources under k8s folder, I pass folder path as below.

Running this you will see the output as below (ignore other errors as I have other policies). The test failed because we have set deny rule if spect.replicas < 2 and in our case our deployment yaml has replicas: 1 (see spec section in the deployment yaml above).

Conftest failing due to policy violation

Using Conftest in GitHub Actions

Making Conftest work in your Continuous Integration (CI) process is simple. For demo purposes, I am using GitHub Actions in my repo here. If you run the tests, you will see the action fails with errors – see the output

My action workflow looks like below.

name: build

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: install conftest
        run: |
          wget https://github.com/open-policy-agent/conftest/releases/download/v0.30.0/conftest_0.30.0_Linux_x86_64.tar.gz
          tar xzf conftest_0.30.0_Linux_x86_64.tar.gz
          sudo mv conftest /usr/local/bin
          rm -rf conftest_0.30.0_Linux_x86_64.tar.gz

      - name: run conftest
        run: |
          conftest test $/k8s

Conclusion

As you can see, Conftest lets you validate and govern your Kubernetes resources efficiently and can easily be integrated with your CI workflows. This lets your team standardise the common practices, go through PR review process before eventually deploying to the cluster. Once deployed to cluster, you can use Gatekeeper to validate as well to full proof your workloads.