Cyber Security

Should AI Guard Your Code? A First Look at OpenAI’s New Security Agent, Aardvark

The Problem: Too Many Holes in the Net Every piece of software you use, from the apps on your phone to the complex systems running hospitals and banks, has code. And wherever there is code, there are bugs. Specifically, security bugs, or “vulnerabilities.” Right now, human security teams are in a constant, losing race to find and fix these holes before hackers can sneak through them. It’s a huge, exhausting job, and the number of new security issues discovered annually is massive. OpenAI is stepping into this problem with a new tool called Aardvark. Think of it as an autonomous, tireless security researcher, powered by their advanced language model, GPT-5. The main goal is simple: to help the “good guys” (defenders) win the race by finding and fixing security flaws in codebases faster and on a much larger scale than humans can manage alone. How Aardvark Works: An AI That Thinks Like a Detective What makes Aardvark different is that it doesn’t just use simple automated checks. Instead of running traditional, dumb tests, it actually reads and reasons about the code like a human expert would. Here’s the step-by-step process it follows: Understand the Plan (Analysis): It first looks at the entire codebase to understand how it’s supposed to work. It builds a kind of “threat model” of the project’s security goals. Watch the Changes (Scanning): As new code is written and committed, Aardvark scans it immediately, comparing the changes against its threat model to spot potential weaknesses. It can even go back and scan a project’s history for old issues. Prove the Weakness (Validation): If Aardvark thinks it found a bug, it doesn’t just guess. It tries to exploit the flaw in a safe, isolated, sandboxed environment. This helps ensure that the vulnerabilities it reports are real and can actually be used by an attacker, which cuts down on annoying false alarms. Offer a Fix (Patching): Finally, Aardvark doesn’t just point out the problem; it also uses its AI tools to generate a clean, targeted patch (the fix) that can be reviewed and applied with a single click. Quick Review: The Good and The Unknown Pros (The Upside) Unmatched Scale: Aardvark can scan massive amounts of code instantly and constantly, something human teams simply cannot do. High Accuracy: In early testing on known security issues, the agent successfully identified an impressive 92% of the flaws. Real-World Impact: It’s already been used internally at OpenAI and has helped them responsibly find and disclose flaws in open-source projects, some of which have received official CVE identifiers (official security warnings). Efficiency: By finding the bug and proposing the fix at the same time, it prevents security from becoming a bottleneck that slows down the entire development process. Cons (The Caveats) Still in Beta: This technology is currently only available to select partners in a private beta. It’s not ready for everyone to use, and it needs more real-world testing. Not Fully Autonomous: Aardvark is a powerful tool, but it’s not a replacement for humans. Its findings and proposed fixes must still be reviewed by human security experts before they are applied. The Unknowns of AI Reasoning: Because it relies on LLM reasoning rather than fixed rules, there is always a chance it could miss a vulnerability that a human would spot, or introduce a new kind of logic error. Is It Too Early to Adapt AI Security Agents? The short answer is: It’s too early to rely on them, but not too early to start planning for them. We are clearly past the point where AI is just a gimmick in the security world. Tools like Aardvark demonstrate real, measurable power in helping to defend software. However, the fact that Aardvark is still in private beta and still requires human review for its patches tells us where we are in this journey. AI security agents are not here to replace the human security team yet. They are here to be a highly effective, incredibly fast partner. They will handle the massive, repetitive scanning and validation tasks that bore human experts, freeing up those humans to focus on the deep, complex, creative attacks that only a human mind can anticipate. For now, the best strategy is to watch how Aardvark performs as it rolls out, and to be ready to integrate it into your security strategy the moment it becomes widely available. The future of software security isn’t human or AI; it’s going to be human and AI working together.

Should AI Guard Your Code? A First Look at OpenAI’s New Security Agent, Aardvark Read More »

Inbrowser-RDP-mr.viind-blog cloudflare

In-browser RDP with Cloudflare Tunnel — Complete practical setup on (Tested and working on windows 11)

This is a hands-on, step-by-step guide post you can use to publish a Windows host with in-browser RDP using Cloudflare Tunnel and Cloudflare Zero Trust Access. Read it once, then follow each step. I wrote this so you can copy, paste, edit small values, and run a single PowerShell script at the end to finish the setup on Windows. Short summary I had my domain registered with hostinger so  i moved my domain DNS management into Cloudflare, point your domain (update nameservers at Hostinger), create a Cloudflare Tunnel, install the tunnel agent on Windows, configure the tunnel to route a public hostname to an internal RDP host, create a Zero Trust Access app (RDP with browser rendering), and test from a browser. Step 0 — Key information you should have A domain name (example: yourdomain.com). Cloudflare account with Zero Trust (Access) enabled. Hostinger account where your domain currently has DNS (so you can change nameservers). Windows machine where you will run cloudflared (Administrator access required). Private IP of the RDP target (example: 192.168.1.100), and RDP enabled on that target. Step 1 — Add your domain to Cloudflare and switch nameservers (I had my domain registerd on Hostinger) Log in to Cloudflare and add your domain (the dashboard will give you two Cloudflare nameservers). Log in to Hostinger, find your domain’s DNS / Nameservers section, and replace the current nameservers with the two Cloudflare nameservers Cloudflare gave you. Save changes. Wait for Cloudflare to accept the domain (it typically takes a few minutes to a few hours to propagate). You can check the Cloudflare dashboard until the domain shows as active on Cloudflare. Once active, Cloudflare manages DNS for your domain and you will perform public hostname mapping within the Cloudflare dashboard on this process, later. (no more changes needed at Hostinger for the hostname you will use). Step 2 — Prepare Zero Trust and create a Tunnel Do this in the Cloudflare dashboard under Zero Trust (sometimes called Cloudflare for Teams / Access → Tunnels). The UI may show options to create tunnels or generate a one-time service install token. Follow the UI to create the tunnel and either: Generate a one-time service install token (recommended for unattended Windows service install), or Create the tunnel and note the Tunnel UUID (if you prefer interactive CLI login later). Also in Zero Trust you will create network routing entries (CIDR / routes) so Cloudflare knows which internal addresses the tunnel can reach: Under the Zero Trust / Network or Tunnels area, add the internal network routes (CIDR ranges) or specific IPs that the tunnel should be able to reach — for example your LAN range or the private IP of the RDP host (e.g., 192.168.1.0/24 or the single IP 192.168.1.100). Create any network policies required to allow the tunnel to access those CIDR ranges from the Cloudflare side (these options vary by UI but are usually grouped under “Network” or “Private networks”). Step 3 — Create targets and allow admin users Still under Zero Trust, register the internal target(s) you will access (the RDP host IP). This tells Cloudflare where to forward inbound session traffic that arrives via the tunnel. Create a Zero Trust policy or Access rule that allows your admin account(s) to use the application. This is done in Cloudflare Access / Policies — add an “Allow” policy that specifies the Cloudflare user or group who can open the RDP app. Step 4 — Configure a public hostname (Public Hostnames / DNS) You will map a hostname that your users can visit in the browser to reach the tunnel and then the RDP target. Go to Zero Trust → Tunnels → your tunnel → Public hostnames (or Public Hostnames / DNS mapping area). Add a public hostname, for example rdp.yourdomain.com. Set the service to the internal RDP target: rdp://192.168.1.100:3389 (replace with your private IP and port if different). Save. Cloudflare will create the correct CNAME behind the scenes (it points the public hostname to [TUNNEL_UUID].cfargotunnel.com), or you can create that CNAME in Cloudflare DNS manually if needed. Step 5 — Create an Access application (Browser RDP) In Zero Trust → Access → Applications, click Add application. Set Application domain to rdp.yourdomain.com. Choose Application type: Self-hosted and select RDP. Enable Browser rendering (this renders the RDP session in the browser). Create an Allow policy that includes your Cloudflare user (email) or a group that contains the admin accounts. Save the application. Step 6 — Install cloudflared and run the tunnel on Windows Below is the one-shot PowerShell script I use. Edit the top variables ($ServiceToken, $tunnelUUID, $hostname, $targetIP) to match your values, then copy the full code in one-go, paste it on powershell, hit enter. $UseToken = $true $ServiceToken = ” $tunnelUUID = ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ $hostname = ‘rdp.yourdomain.com’ $targetIP = ‘192.168.1.100’ $targetPort = 3389 $exeDir = ‘C:\Program Files\cloudflared’ $exePath = Join-Path $exeDir ‘cloudflared.exe’ $sysCfgDir = ‘C:\Windows\System32\config\systemprofile\.cloudflared’ $configPath = Join-Path $sysCfgDir ‘config.yml’ $credPath = Join-Path $sysCfgDir ($tunnelUUID + ‘.json’) If (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) { Write-Error ‘Run PowerShell as Administrator’; Break } New-Item -ItemType Directory -Force -Path $exeDir | Out-Null $downloadUrl = ‘https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64.exe’ if (-not (Test-Path $exePath)) { try { Invoke-WebRequest -Uri $downloadUrl -OutFile $exePath -UseBasicParsing -ErrorAction Stop; Unblock-File $exePath -ErrorAction SilentlyContinue } catch { Write-Error “Download failed: $downloadUrl”; Break } } & “$exePath” –version Get-WmiObject Win32_Service | Where-Object { $_.PathName -and ($_.PathName -match ‘cloudflared’) } | ForEach-Object { try { Stop-Service -Name $_.Name -Force -ErrorAction SilentlyContinue } catch {} sc.exe delete $_.Name | Out-Null } taskkill /IM cloudflared.exe /F 2>$null New-Item -ItemType Directory -Force -Path $sysCfgDir | Out-Null if ($UseToken) { if (-not $ServiceToken) { Write-Error ‘Set $ServiceToken’; Break } & “$exePath” service install $ServiceToken Start-Sleep -Seconds 2 } $possibleCreds = @(“$env:USERPROFILE\.cloudflared\$tunnelUUID.json”, “C:\ProgramData\cloudflared\$tunnelUUID.json”, (Join-Path $exeDir ($tunnelUUID + ‘.json’))) $found = $possibleCreds | Where-Object { Test-Path $_ } | Select-Object -First 1 if ($found) { Copy-Item -Path $found -Destination $credPath -Force; Write-Host “Copied credentials to $credPath” } else { Write-Host “No credential file found; service may be running with token mode.” } $ingressService

In-browser RDP with Cloudflare Tunnel — Complete practical setup on (Tested and working on windows 11) Read More »

Scroll to Top